Is there a way to detect web server in case it's not present in HEADER? I'm trying to detect what web server a particular website uses. For instance whether it's nginX, Apache, Tomcat and so on.

I usually use Live HTTP Headers Firefox add-on. The problem is that sites sometimes hide their back-end. Isn't there a way to detect web servers when they're not present in HEADER?

EDIT 1:
A sample output from a website that didn't match to any of the @Question Overflow's answer:

HTTP/1.1 200 OK
Date: Mon, 29 Sep 2014 10:43:29 GMT
Content-Type: text/html
Transfer-Encoding: chunked
X-Powered-By: VideoHosting Framework/1.0.1
Cache-Control: no-cache, must-revalidate, no-cache="Set-Cookie", private
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Videohost/1.0.1

I even tried to use httprint on linux but it gives ICMP request timeout on every website I tested.

EDIT 2:
The above HEADER is very similar to a website that I'm sure it uses nginX.
If we remove those parts that are not present (Connection, Pragma and so on) in the above HEADER, it gets so similar to nginX. I suppose Server is at the end of the response because they have customized it themeselves. And because of that nginX appended it to the end of the Response packet.

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 29 Sep 2014 12:51:37 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Encoding: gzip

OWASP should update its list with this one as well for nginX. ;-)

If a website does not use a custom built server to modify the HTTP headers, you can try by examining the order of arrangement in the HTTP response fields. From OWASP:

Apache 1.3.23 server:

HTTP/1.1 200 OK
Date: ...
Server: ...
Last-Modified: ...
ETag: ...
Accept-Ranges: bytes
Content-Length: ...
Connection: ...
Content-Type: text/HTML

Microsoft IIS 5.0 server:

HTTP/1.1 200 OK
Server: ...
Expires: ...
Date: ...
Content-Type: text/HTML
Accept-Ranges: bytes
Last-Modified: ...
ETag: ...
Content-Length: ...

Netscape Enterprise 4.1 server:

HTTP/1.1 200 OK
Server: ...
Date: ...
Content-type: text/HTML
Last-modified: ...
Content-length: ...
Accept-ranges: bytes
Connection: ...

SunONE 6.1 server:

HTTP/1.1 200 OK
Server: ...
Date: ...
Content-length: ...
Content-type: text/html
Date: ...
Last-Modified: ...
Accept-Ranges: bytes
Connection: ...

For further confirmation, you can send a malformed request, such as GET / HTTP/3.0, to elicit a non-standard response. Example:

Apache 1.3.23 and SunONE 6.1 servers:

HTTP/1.1 400 Bad Request

Microsoft IIS 5.0 server:

HTTP/1.1 200 OK

Netscape Enterprise 4.1 server:

HTTP/1.1 505 HTTP Version Not Supported

As the above information is pretty outdated, you may want to install a pentesting tool like httprint for automated web server fingerprinting.

Web servers can obfuscate their signature or masquerade themselves as another server. Take the information with a pinch of salt, if you must.


Exploiting SQL Injection Vulnerability Using Logical Errors <?php
/*
CREATE TABLE `message` (
`remote_addr` TEXT NOT NULL ,
`user_agent` TEXT NOT NULL ,
`name` TEXT NOT NULL ,
`text` TEXT NOT NULL
) ENGINE = MYISAM ;
INSERT INTO `message` (`remote_addr`, `user_agent`, `name`, `text`) VALUES('127.0.0.0', 'Fire Walk With Me', 'test name',
'test text');
INSERT INTO `message` (`remote_addr`, `user_agent`, `name`, `text`) VALUES('127.0.0.0', 'Abandon all hope, ye who enter
here', 'test name2', 'test text2');
*/
$link = mysql_connect("localhost", "root", "");
mysql_select_db("positive", $link);
$ip = $_SERVER["REMOTE_ADDR"];
if(isset($_SERVER["HTTP_X_REAL_IP"])) {
$ip = $_SERVER["HTTP_X_REAL_IP"];
}
$ip = addslashes($ip);
$user_agent = addslashes($_SERVER["HTTP_USER_AGENT"]);
$ip = substr($ip, 0, 15); // max length 15
if(isset($_POST["name"]) && isset($_POST["text"])) {
$text = addslashes($_POST["text"]);
$name = addslashes($_POST["name"]);
$query = mysql_query("INSERT INTO `message` (`remote_addr`, `user_agent`, `name`, `text`) VALUES('{$ip}',
'{$user_agent}', '{$name}', '{$text}');", $link);
}
$query = mysql_query("SELECT * FROM `message`;", $link);
echo("
");
while($row = mysql_fetch_assoc($query)) {
echo("
{$row["name"]}	{$row["text"]}
");
}
echo("
");
?>

I'm trying to find SQL Injection in this code. I tried different methods but I didn't succeed. The clue is "Try to find logical errors in this example of code". I know that there is a possibility that DB has GBK (or something else) encoding and we can use multibyte character to broke the statement. But it is not appropriate in this case.

I don't understand why do we do addslashes on $ip. It seems unnecessary. Maybe it is a clue.

h/t to @Peter for helping iron out the details

The trick is that add_slashes is applied to the IP address and then it is truncated to 15 characters. Imagine injecting this into $_SERVER["REMOTE_ADDR"] or $_SERVER['HTTP_X_REAL_IP'] (the 15th character is a single quote):

12345678901234'

add_slashes turns it into this:

12345678901234\'

Which is truncated to this:

12345678901234\

Aka, now you have a lone trailing slash that will escape the single quote that was supposed to end the value for the IP address in the query. You have now modified the query itself. The opening quote of the user agent value now closes the  IP address value, and anything in your user agent is inserted into the query directly without being inside any quotes.  You'll just have to make sure you build a valid query when you are done.  Injecting data into $_SERVER['REMOTE_ADDR'] is difficult because, although you can spoof it on the TCP request, this will break the handshake and the HTTP request will never happen.  However, setting $_SERVER['HTTP_X_REAL_IP'] is as simple as setting a header on the request.  So something along these lines would work (this is a hastily thrown together example without testing):

curl 'https://target.com' \
    -H "X-REAL-IP: 12345678901234'" \
    --user-agent '1,1,1); INSERT INTO message (name) SELECT
 CONCAT(Host,User,authentication_string) from mysql.user; --'

Note that this particular example is only possible because of the use of the old mysql_query bindings.  The mysqli library explicitly disallows having more than one query in each execute statement.


Access to email without antivirus I am doing a test where we want to asses whether an email with a benign virus in it, exits a network.

I need a means to receive the test emails I am sending from inside the network, without any antivirus or spam filters, and I need to receive them outside the network.

The problem is that all the online email services I have access to have anti virus protection, and will delete any messages sent from the network containing viruses before they reach my inbox. This makes it impossible to assess whether the emails where sent and received, and what viruses they contained.

Do you know of any email solutions (preferably online) without antivirus, or where I can turn it off?

I ended up setting up my own mail service on a server using pythons smtpd module and configuring mx records to point to my new service.

This solution is cumbersome to me and if you have an easier one, then please let me know.

What about a minimal UNIX VM somewhere on your network (e.g. an Ubuntu live on your workstation) and then use the mail command?

You might want to configure a basic mail transfer agent to correctly queue mail to your SMTP server. Ubuntu uses Postfix, but there are many more such as Qmail and if you're brave, Sendmail.

Configuring a mail server is not an easy task and it might break your company policy. Make sure you're not doing anything contrary to your company's policies here.

Your solution with Python is also a good one.

And for a very, very basic solution there's also telnet.


Is it possible to ensure that firmware doesn't keylog? Not a conspiracy theory, just a thought experiment.

Let's say some big smartphone manufacturer put keylogger (or any other malware) in their hardware. Would it be possible to reveal it with 100% certainty?

No. You cannot always detect. Here is a scenario.

How would the keys be logged? Each time you press a key you send an interrupt to the processor because some wire that was low goes high on a bus that says hey CPU, I have input for you to read!  The CPU reads the input and puts it somewhere and tells the application a key was pressed.

So firmware could be any other chip that also monitors the bus, and captured the value when it goes high.

It doesn’t need to be the cpu and it can write the data anywhere. It can wait for some sequence of data before it kicks off its own interrupt to the cpu to read the data, or writes the data out to a port like usb.

It might be detectable if the firmware is sending the data over the network from time to time, but definitely possible to simpler store and wait for instructions before revealing it.


What all test cases/vulnerabilities we need to try in REST API Pen testing? I am learning API pen testing and looking for resources which will give clear list of test cases we need to check while performing a Pen testing on REST API.

I have gone through the OWASP resources API Security Cheat_sheet.

Still I have some confusion. Can anyone give me the list or links where I can find the REST API security checklist?

There is no standard list of test cases here. OWASP’s cheat sheet is a good start. Otherwise, define your threat model and just test against it, as tailored to your application. These are the struggles of security testing (or any kind of testing really I’m afraid). Good testing design requires analysis of the target application, so us out here on the Internet can’t really give a useful answer without knowing your application. Good luck!


How to check for presence of LM hashes in local SAM To get rid of LM hashes in local SAM databases, one can rely on the famous NoLMHash domain GPO, which instructs clients not to store password hashes with the LM algorithm locally ("Do not store LAN Manager hash value on next password change").

However, as the policy's label clearly mentions, it has no immediate effect to hashes already stored in various clients' SAM databases. Of course, each user will have to change his password in the next few weeks, and the NoLMHash policy will be enforced such that their new password's LM hash won't be stored anymore, but this isn't true for any other user who logged in on that same station in the past (think of IT staff, help-desk support, user who previously owned that same computer, etc.). These passwords will never be changed on that same workstation again, and thus are still vulnerable to LM hash reversal (or did I missed something?). Even if these reversed passwords are not valid anymore because of the rotation policy, an attacker could probably easily find a pattern among all users (if a given LM hash is reversed to, say, "Colorado$04-2014" and this password has expired, there's still a chance that this user's subsequent password has been set to something like "Colorado$07-2014").

My question is: is there a way (a command, a script, whatever) to find out if there still are LM hashes stored on a given computer? Said in another way, I would like to make sure that, on a given computer, only NTLMv2 hashes are stored.

Thanks for your help!

The reliable way to check this, I think, is to put yourself into attacker's position, dump hashes, and see if LM hashes show in those dumps. You can do this with variety of pwdump-like tools.

I haven't done this in a while, but if memory serves, output file contains user name and id, along with LM and NTLM hashes. If LM hash isn't present, it will be clearly visible in the file.


Mail : non existent domain FROM field I'm wondering if during the process of sending a message, the domain indicated in "from" field is checked?

I know there is no integrity control of the from field, but I tried to send a message to an existent domain with "test@nonexistentdomain" and it does not work.

Maybe it's the MTA?

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

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

Other MTAs will have similar options.

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


Preventing reverse-engineering of client application I have a web service which is used by a Flash client. Both the service and the Flash client is produced by me (read: my company). The Flash client communicates with the server over HTTPS.

One of the issues we have seen lately is that people decompile the Flash client and then create their own clients to interact with the server. This is not a huge issue, since the server has a lot of "controls", but it is annoying.

I know about Flash obfuscation, but my question is a bit more generic: Assuming you distribute client software to work with your web service, what measures would you take to limit the risk of people tampering with your client software?

Obfuscation might look as the first obvious step, but obfuscation has to protect something in the code and that something cannot be webservice functionality because that is reverse engineered by intercepting the traffic even if it is SSL encrypted. Certificate pinning can prevent simple SSL interception by trusting a predefined certificate.

You can symmetrically encrypt communication data and store the key in the client then use obfuscation to make access to that key and encryption algorithm harder. And you can also protect the obfuscation by making decompilation harder. An example flash obfuscator and anti-decompiler is SWFencrypt and BISguard.

The previous are static source code protections but they don't guard against live/dynamic attacks. One way of protecting from these attacks is for the client to use integrity checks on memory and resources. There are also some anti reverse engineering techniques that can make live debugging harder.

The other way to prevent against live attacks is to use software that looks for any system tampering that may be used for client software tampering. This is the realm of rootkit-like anti-cheat engines like Punkbuster, Warcraft's Warden and Valve's VAC.

A different kind of protection is code signing and memory signing (down to the memory page) on closed platforms like iOS and Android. This way, you can limit static modifications to the client's binary and dynamic ones to its memory and the OS.

Even the old CAPTCHA can be used as protection against automation but it hurts user friendliness. You can also detect automation on the server, through user behavior and usage patterns then couple it with CAPTCHA to reduce false positives.

Aside from technical protections, you can use with legal means and even incentives. Provide the best client so users won't be inclined to hack yours or write their own. Or make it so that a custom or hacked client won't give the hacker a far greater advantage. Legal means are not my strength and will vary by country, but I've heard about lawsuits on reverse engineering. Legal threat might deter companies and individuals from selling or providing custom clients.

Finally, you can turn the whole problem on its head and make the webservice easily accessible through flexible APIs and protect against abuse on the server. You might also  charge small fees for the superior functionality your hackers are craving for. :)


Penetration test limitations with a virtual machine What are the limitations when performing a penetration test with a virtual machine instead of a physical one?

In my opinion performing a penetration test from a virtual machine is actually the preferred way of doing it from opsec perspective (i.e. to maintain separation between your clients' data).

Limitations may arise from the fact that you can't access the underlying hardware directly, in particular:

Wired network interfaces: some host operating systems (e.g. OSX) will continue using the wired network even if you explicitly disable it in host OS and bridge the virtual machine to it. From the network perspective that means two separate MAC addresses on the same port, which sometimes triggers the NAC.
Wireless interfaces: most hypervisors don't emulate wireless devices at all
GPU: if you want to use something like oclhashcat for password cracking, you need direct access to the GPU

That being said most of these problems can be solved by dedicating the necessary hardware to the VM (e.g. PCI or USB passthrough).


Are Yubi Keys secure "out of the box" when purchased for use with Yubi Cloud? The YubiKey personalization tool allows someone to configure a YubiKey for HOTP, challenge response, and a variety of other authentication formats.

YubiKey offers a number of personalization tools for both logical slots of the hardware device.

When I ran the personalization tool on OSX it appears I can view and edit the default "secrets' of the device.

(actual values redacted for privacy)

Question

Is it correct that a default shipment of a Yubikey can  have its secrets read with anyone with this software?
Is the only and correct way to secure a yubi key is to set a password using the following utility?

TL;DR

You may be misunderstanding the security trade-offs that a YubiKey offers. All security controls involve trade-offs; YubiKeys with YubiCloud authentication involves key escrow.

Authentication with YubiKeys

Out of the box, YubiKeys are pre-configured to authenticate against the YubiCloud. The default mechanism appears to involve storing your AES secret key server-side. Yubico claims:

  There is no access to AES secrets even for administrations of the backend KSM servers.

Even if true, I would expect any key-escrow system to be fundamentally vulnerable to physical threats and brute-force attacks. Assuming you trust Yubico to escrow your keys in the first place, anyone with physical control of the Hardware Security Module or its contents could mount an attack.

The bottom line is that if you use the YubiCloud authentication mode, you will be trusting Yubico with your secret key even if you change it. Changing your key only makes sense if you are using an alternative back-end for authentication, or if you believe your currently-stored key has been compromised in some way.

Password Protection in the Personalization Tool

What this feature is doing is providing an administrative password for preventing re-configuration of the key. You may want to look at the source code, but the "Configuration Protection" password is just that: a password to prevent unauthorized changes to the key. Section 3.2 of the API documentation says:

  [T]his approach is targeting destructive attacks as the interface does not provide any means of retrieving secret information. The configuration interface is write only, and the term destructive attack refers to an opponent that wants to erase or modify the settings of a device.

In my opinion, this feature is most useful in preventing end users from misconfiguring or re-purposing an organizationally-owned YubiKey. Your mileage may vary.


Bogus HostName Causing Suspicion of Man In The Middle I have servers on a LAN reporting my laptop with a bogus hostname. This is making me suspect a man in the middle attack.

Here are some details:

From an Ubuntu Linux 14.04 laptop, I logged into an Ubuntu server to do some bandwidth monitoring with a tool call jnettop.

jnettop lists all computers connected to the server and how much bandwidth each connection is consuming.

On a debian-based linux you can install jnettop like this:

sudo apt-get install jnettop

And to run jnettop, you type a command specifying the network interface you want to listen on, like this:

sudo jnettop -i eth0

Naturally, one of the connections jnettop listed was my own port 22 connection with the server. It correctly indicated my local ip address, but for my host name it said I was julianm.domain.local; I was expecting it to say myActualHostname.domain.local

As a hostname, "julianm" is definitely not something I recognize and I'm concerned I may be falling victim to a man in the middle attack. What are other explanations as to why jnettop would report an incorrect hostname for its connection with this laptop?

Any advice would be appreciated. Thanks.

It is possible that is what is happening. Assuming this isn't a super sophisticated attack, let's take a basic overview of what to do:

First, check your Domain Name Server (DNS) to get a mapping of current IPs to Media Access Control (MAC) addresses.

Next, you need to log-in to your network switch(es).
Within your switch, you will be able to view the Content Addressable Memory (CAM) tables.
These tables map each MAC address to the physical port that they are plugged into on the switch.

Once you have the physical port, you can go to that location and look for a bad actor.
Additionally, unless the MITM is spoofing their MAC, you may also be tipped off as to what kind of device to look for by looking up their vendor code: Mac Vendor Lookup

This process can be further complicated by unsecure wireless access points.


Is encrypting SALT with given user's password more secure? I'm learning about web security. I understand that passwords are hashed with salt. Why aren't the salts encrypted with same user's password? Cloudn't this make password cracking much harder?

Generating

generate salt
encrypt it with AES using user's password as key
save the encrypted salt and hash

Retriving

decrypt salt using supplied password
hash salt + password
compare to saved hash

generate salt encrypt it with AES using user's password as key save
the encrypted salt and hash

You could do this and it would be an effective salt, however it wouldn't actually be any more secure than just using a regular salt.
Let's consider two attack vectors:
Password collisions
Obviously we don't want two users with the same password to have the same hashed password. To prevent this we use a random salt and assume that the probability of two users with the same password and the same randomly generated salt is effectively 0.
However, if two users happen to have the same password and coincidentally the same salt then they will have the same hash regardless of whether the salt is encrypted with their password or not encrypted at all. Therefore, by encrypting the salt you're not making it any less likely that a collision will occur in the salt. The only factors which do make it less likely is the quality of the random values used for the salt and the number of bits.
Brute force attacks
If an attacker is trying a brute force attack and you've encrypted the salt the only extra step they have to do is decrypt the stored salt each iteration and use that to produce the hash they then compared to the hashed password to see if they have a match.
This does require marginally more effort for an attacker, but when it comes to cryptography making something take only two or three times longer isn't significant. If brute forcing a password now takes 3 days instead of 2 you haven't really made it materially more secure. If you're trying to make something secure you want it to take 5000 years instead of 2 days.
If you want to slow down brute force attacks you'd be better off iterating your hashing process tens of thousands of times or using a hash function which is specifically designed to be computationally slow.


How to get CSRF token on authorization request with OWASP ZAP in bruteforce mode I am a new in OWASP ZAP, so I need your help.

I have vulnerability site - DVWA. I am trying to work on token (CSRF) in bruteforce.

When page load I have HTML form with login, password and user-token. Third field are filled by dynamic token (CSRF).

I need to use bruteforce with CSRF token.

Receive user_token from loaded page
Send form through Fuzzer

As I understand, I need to create script for receiving user_token from loaded page and then run Attak -> Fuzz on authorization link, then select user_token value and add playload script that will fill it on each request.

But I can't find any information on the Internet how to create this script. Can anyone please help me?

Theres actually an easier option when using the fuzzer.
Add the 'Anti-CSRF Token Refresher' Message Processor - that will automatically regenerate the token for you :) If its not available then you should just need to tell ZAP about the token name.

Its worth noting that currently we only support CSRF tokens in the body, not in the URL.

Oh, and FYI in the next version of the fuzzer addon this Message Processor will be added by default if we detect a CSRF token in the message being fuzzed :)


Service changing port when scanned with nmap While scanning a host with nmap I have discovered an unusual service. The service moves to another port everytime I perform an nmap-scan or try to curl it. I have not yet found any info about similar cases, so I am currently not sure how to move forward. Are there any ways I can try to connect to the service, without the service moving to another port?

This sounds like port knocking. Port knocking is where you connect to a sequence of ports before a port is exposed that allows you to connect to a specific service.
Some people like to use it as an extra security measure to lockdown SSH.
For example lets say I've configured my server to listen on port TCP/1111, then when someone connects to TCP/1111 it will open TCP/2222 and so on until finally port TCP/22 opens and I can SSH to my device.
You can read more about how this works in the below link.
https://www.howtogeek.com/442733/how-to-use-port-knocking-on-linux-and-why-you-shouldnt/


Authentication as CIA triad As we all know, information security principles are stated as CIA triad, i.e., confidentiality, integrity, and availability. I wonder why authentication is not a part of CIA triad as being an important factor in information security. Does it belong to another classification?

CIA are the aspects of a system that information security strives to protect.  Authentication and authorization (important and distinct concepts) are security controls that are used to protect the system with regard to the CIA properties.  For example, authenticating a user and checking that they are authorized to access the data ensures the confidentiality of that data.  Authenticating and then authorizing for modification is helping to ensure integrity of the data.


Keysigning and digital message signatures: are they the same thing? I was reading this wikipedia article on Keysigning: https://en.wikipedia.org/wiki/Keysigning and I then came across this discussion Stack overflow about message signing with RSA: https://stackoverflow.com/questions/454048/what-is-the-difference-between-encrypting-and-signing-in-asymmetric-encryption
In reading them it seems they are slightly different things but I wanted to double check I'm not misunderstanding what I've read. Could someone please clarify if they are the same or different things?
From what I am understanding, key signing is using a Certificate that proves you are the owner of a private key to sign someone else's Certificate, proving to a 3rd party that you trust that the presenter of the certificate owns their private key. This is normally done in PGP systems.
Message signing is using your private key to generate a message signature that can be read by anyone with access to your public key. So, if I took today's date and a nonce and signed them with my private key I'd produce a hash that anyone with my public key could retranslate back into todays date and read.  This can be incorporated into a message to prove to the receiver that you are the sender.
Both the digital signature and the key signature have the common ground that you can use the signers public key to verify that they are the one who signed it, but they server different purposes.
Is my understanding of both correct?
Thanks

Digitally signing some "message" is a generic concept. Digitally signing a PGP key is part of this broader concept, with the "message" being the signed key.
A digital signature proves only that somebody has signed the message. It is up to the specific use case on what it means if a message is signed. I.e. the technology of signing is the same, but the meaning (semantics) can be different for different use cases.
In case of signing a PGP key it means that the signer has somehow verified that the key belongs to the one claimed in the key. Similar in case of signing a X.509 certificate (like used in HTTPS) it means that the certificate authority (the "issuer" of the certificate) has somehow verified that the claimed subject of the key (like a domain name) actually belongs to the owner of the certificate. In case of a digitally signed mail it means that the mail is actually created by the one who signed it.


Encrpyting HTTP sensitive data without SSL certificate I am implementing a server that contains most of the information the clients have to retrieve. Sensitive information has to be exchanged between client and server, and due to this, I would like to have this information encrypted.
I came up with the idea of encrypting all sensitive information using RSA (PKCS1_OAEP) by having every client and server generating and exchanging their public keys to encrypt, and to be decrypted by the receiver.
What is the catch here? Is it unsafe to do this?
I understand https exists, I am just wondering about this solution.
I understand size is a "limitation", but one way of going around this is encrypting packets, then joining all the packets in a single string to then be decrypted in the same way.

Just don't do it, for many reasons:

RSA by itself should not be used to encrypt many bytes - RSA maximum bytes to encrypt, comparison to AES in terms of security?
Assuming that you are using RSA together with a symmetric cipher as it is usually case the (in)security depends on the details - i.e. symmetric algorithm, key size, integrity protection etc. There are many pitfalls here.
Apart from that the RSA keys not only need to be exchanged first but also each has to be sure that it has the correct key of the peer and not the key of some man in the middle who injected itself during the key exchange.
And it does not provide any forward secrecy, i.e. once a key is compromised (private key leaked) all previous messages can be decrypted.

And these are only the more obvious points. Crypto is a really complex issue and even experts get it wrong. Don't even try to design your own system unless you understand the design of established systems and why they were done this way.


Can a Ubuntu live usb be infected with spyware/ virus? I have a Ubuntu 13.10 live usb. I gave it to somebody so that he can install ubuntu. Now I have received it back. I was wondering if it is possible to infect a live usb with spyware or virus ? If yes, how to detect it ?

Of course it can. I presume you didn't make your USB stick irreversibly read-only in hardware (can be done, but it's rather fiddly, and in case of using the read-only switch, it can of course be easily moved back in write position, if your drive even has one), so what you got back on your stick could be anything, unless you check that the complete contents of your drive match the ones you gave away.

The easiest way out is probably by formatting the drive and reloading it with a new copy that you hold and nobody could tamper with, or downloading it again from a trusted source. Alternatively, you could calculate checksum of all the files on the drive, and compare them and the rest of file metadata (like timestamps) with those you calculated and noted previously, or the ones you find online where you downloaded the files from, to check for evidence of them being tampered with.


Is it dangerous to add a custom cert authority to a browser? For example if my friend develops a webapp with a custom cert and I add them as CA to my browser, can they do any damage? I mean for example somehow faking certs and stealing my banking password, etc.? Are there such risks with custom cert authorities?

Is it dangerous to add a custom cert authority to a browser?

It is pretty dangerous. The owner of this CA can use it for man in the middle attacks or to impersonate arbitrary web sites since your browser will trust the CA to create certificates for arbitrary sites. Using such attacks he can then intercept your passwords and other sensitive data.

  For example if my friend develops a webapp with a custom cert and I add them as CA to my browser, ...

There is no need to import the certificate as CA into the browser. You can just import this specific certificate as trusted as server certificate but not as CA certificate. If you do it this way it can only be used to MITM and impersonate sites which are covered by the certificates subject/SAN.

Or you can just add an exception if the browser warns you. In this case the certificate is only treated as valid for the site you visited but not for all the other domains which might be covered by the subject/SAN.


Prevention of user's passwords being stored as plain text in bash history Say I want to find the password of a linux user sudoer account. Assume he uses a strong password. Assume I have physical access to the machine. I can get hold of his passwd and shadow file and brute-force it for days, or simply get a copy of his bash history file and use it as a word-list.

I am not a hacker, but this method has worked a lot of times when I wanted to hijack someone's account. In my openion, a lot of people accidentally type there password on the command-line, especially if they don't touch-type.

Lolz, I don't touch type either. Nor do the users of the systems I manage. How can I make sure that my super-strong password is not stored as plain-text in my .bash_history?

I know I can keep deleting bash history, but is there any other means?

You can't, and you shouldn't try for the following reasons:

Imperfect technical ability (semantics)
Imperfect technical ability (centralized logging)
Alternate vectors (process table)
Best practices (teach correctness)

Imperfect technical ability (semantics)

Let's assume you actually want to have a history file - it exists for a reason; helps you remember commands you typed, repeat commands by reference, etc. etc.  In this case, you want to remove passwords that you've mistakenly entered.  How do you do that?

You could have a plaintext list of passwords that you scan for within bash history files.... but then you have a list of plaintext passwords on your system.

You could look for commands like 'sudo' and 'su' and try to remove things after them... but the thing that's going to happen is someone will type 'sudp' by mistake, then type in their password to the prompt, and your filter won't notice it because of the very typo that led to the password exposure.

In short, the computer isn't smart enough to filter out inappropriate password entries; that's a semantic meaning problem.

Imperfect technical ability (centralized logging)

In bash 4.1, they introduced the ability to copy everyone's history logs to syslog.  This was a legitimized version of functionality that people had been hacking, patching, and scripting into bash (and other shells) for years.  If anybody else administers your machine - say, the IT group at work - then you may not have control over whether your command lines are being logged, quietly, without you ever knowing.

It's not just bash.  The auditd daemon on Linux can be configured to log commands and arguments:

# grep oops /var/log/audit/auditd.log
type=EXECVE msg=audit(1443795447.953:2387443): argc=6 a0="sudo" a1="oops" a2="i" a3="typed" a4="my" a5="password"
#

That's a system-level setting, operating via the kernel, completely unrelated to whatever shell you use and regardless of any history settings you may have chosen for yourself.

Alternate vectors (process table)

Anything you type on the command line may show up in the process table, which is why tools that use passwords require them to be entered interactively.  If you mess up (as in the sudo example above) and enter them as arguments, they're there for someone to grab out of the process list - and it's not that hard for someone to script a harvester that grabs command lines out of the process table.

Best practices (teach correctness)

Each of these objections has caveats... "If I don't want to keep using a history file", "If my sysadmin is hands-off", "If no one is watching the process table carefully"....  But my definition of "best practices" is "stuff you do because you can't rely on other things going the way you'd like them to."  So best practices is simply to assume that any password mistyped where it shouldn't have been is compromised, to change it immediately, and to move on with your life.

Any "solution" you could implement is partial and prone to failures outside the user's detection sphere.  I'd rather not give people the false impression they're safer than they are.

I realize training people to do it is hard.  Heck, training people to do anything is hard, and security is doubleplushard.  But it's the right answer.


CSRF: GET request with POST data? I have stumbled upon a vulnerability in a web application and was wondering if it was exploitable / worth reporting. The bug is a CSRF which would allow an attacker to send friend requests to himself from other user accounts (in turn letting him view sensitive information about the victim accounts). The request is usually made using a POST request. Using usual exploitation techniques, I crafted the following webpage.

        csrf test

        <form action="http://vulnerable.com/friendRequest.asp" method="POST">
            <input type="hidden" name="MessageArea" value="this is a test of csrf">
            <input type="hidden" name="FriendName" value="testuser">
        </form>

Unfortunately though, the website checks for the origin header in the request, so this payload doesn't work. Switching to a GET request and deleting the origin header actually sends the request successfully. The request looks like the following.
GET /friendRequest.asp HTTP/1.1
Host: www.vulnerable.com
User-Agent: Mozilla/5.0
... (no origin header)
Cookie: secret_cookie

MessageArea=this+is+a+test+for+csrf&FriendName=testuser

As you can see this is a GET request with POST data sent at the bottom. Unfortunately the request doesn't go through with the parameters in the URL like in a true GET request. Is there any way to use an external form (like the one above) to send a malformed GET request with POST data to achieve this CSRF? I have looked into XMLHttpRequest and fetch but I'm not sure that they are the right tools for the job.

Is there any way to use an external form (like the one above) to send a malformed GET request with POST data to achieve this CSRF

A GET request with a body has no meaning. To cite RFC 7231 section 4.3.1:

A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.

Since it has no meaning you cannot send a GET request from a browser with a body.


Is it secure for a company to allow you to display your Wi-Fi password when signed onto their site? My ISP, CableOne, has a feature on their site that (when signed onto your account) allows you to retrieve (display on your screen) your Wi-Fi password if you are using one of their modems (which I am). I feel like this is a security issue. I think my Wi-Fi password should be more protected than my CableOne password.  I would like a more informed opinion.

It seems you are talking about factory assigned WIFI router WIFI password.
The default factory WIFI password is meant for the user to connect during initial setup, as well as after hard hardware reset.

You should always change the default WIFI password when you setup the router. After changing the password, the internet reference will be utterly useless unless somebody adjacent to your get the password and able to hard reset your router modem.


Effectiveness of Secure Boot on kernel-mode rootkit detection With so many new patches and updates, how effect is Secure Boot on detecting kernel-mode rootkits?

Secure Boot consists of several components working together ( https://technet.microsoft.com/en-us/windows/dn168167.aspx was my source for how the different components work). Because it works vertically (from the bootloader up) the security of the kernel-mode protection the requires that the lower levels work flawlessly.

Secure Boot

When the PC is turned on the UEFI Bios finds the bootloader. The Bios will only run the bootloader if the bootloader is signed using a trusted certificate or the user has approved the bootloader's digital signature. This prevents and modified/unofficial bootloaders, theoretically stopping bootkits. However this only works if the security is implemented correctly. A little Googling finds several reports of methods that allow a program to bypass the Secure Boot.

http://www.pcworld.com/article/2337180/new-attack-methods-can-brick-systems-defeat-secure-boot-researchers-say.html
http://www.pcworld.com/article/2045793/researchers-demo-exploits-that-bypass-windows-8-secure-boot.html
http://www.pcworld.com/article/2948092/security/hacking-teams-malware-uses-uefi-rootkit-to-survive-os-reinstalls.html
http://www.intelsecurity.com/resources/pr-bios-secure-boot-attacks-uncovered.pdf

I will leave the evaluation of these articles as a exercise to the reader. In addition there seem to be articles that reference bugs in the UEFI implementation of several motherboards. If we assume that these exploits exist then all further Secure Boot steps are compromised, including the Kernel mode root-kit protection.

Trusted Boot

The bootloader then verifies the digital signature of the kernel. Then the kernel verifies the Windows start process. This includes the kernel drivers, the startup files and the ELAM system. If any of these files are corrupted then the computer automatically tries to repair/replace them. If this fails the computer refuses to boot. However this assumes that the bootloader was secured. If that step was compromised then this one could be bypassed as well.

Early Launch Anti-Malware (ELAM)

ELAM starts antivirus software before non-Microsoft boot drivers are loaded. Once ELAM is started it scans drivers as they load. This theoretically prevents malware infected drivers from hiding themselves from the Anti-Virus software, which is normally  not loaded until after boot. ELAM can load either a Microsoft (Windows Defender, Endpoint ect.) or a non-Microsoft anti-malware driver. If a driver contains malware or is not trusted then ELAM will prevent it from loading. This is secure to the point that you trust the anti-virus software to detect driver exploits and malware, which is not guaranteed with new exploits.

Measured Boot

Measured Boot does not prevent exploits, instead it helps in their detection. Using Measured Boot Windows sends logs about the boot process to a secure server. This includes hashes of the boot files allowing any changes to be detected. In order for this to work you need to a. have a secure server setup and b. actively monitor the boot logs.

These potential issues do not mean that Secure Boot does not work. I found very few references to functioning rootkits or bootkits for UEFI systems in the wild. In addition the Microsoft Security Intelligence Reports 18 or 19 (https://www.microsoft.com/security/sir/default.aspx) do not report any rootkits or bootkits. Of course they also make no claims in the reports that Secure Boot fixed these issues.


When (if ever) should web app force numerical, generated (hence hard to remember) logins? Some bank sites force me to use system generated numerical login (ie. 8 digit number). Apart from singnificantly decreasing usability and giving impression of security (to some), does it serve any purpose?
Isn't the security aspect illusionary, since decreasing probability of guessing the credentials can be as well enforced by password complexity policy without making user life that harder?

I'm facing a situation in which such a solution has been choosen for commercial booking/reservation site. I feel that it can seriously decrease the number of users decreasing overall profitability so I'd like to gather broader perspective before trying to influence the choice.

[EDIT] - why most banks use such a solution? Is it just to create an illusion of security?

In my opinion, never.

Like you said, a proper password policy already serves the purpose of lowering the likelihood of a bruteforce attack being successful.

Forcing randomly generated numbers on a user is a sure way to give yourself a headache, as the number of "Forgot Password" request will be overwhelming.

Worst case - it forces the user to write the number down somewhere easy to find.


How do I identify an unknown port/protocol that my IDS picks up? Googling a port and protocol leads to a terse description at best, and a link farm in the average case.  Most protocols on assorted, unknown high ports contain little or no plain text, and often if the IDS trips in the middle of a session I don't even see the session setup.

There are useful lists of file signatures denoting different file types. I've never seen something like this for protocols above the transport layer, besides perhaps the one built into Wireshark.

Does anyone know of a good information source for this?

Another option would be a machine learning classifier for network data.  I've seen papers describing them, and seen projects to build one start, but never found one at a usable stage of development.

Let's see, this should be easy: read a good paper like
Offline/Realtime Traffic Classification Using Semi-Supervised Learning

Then maybe mix in some knowledge from wholly understanding a single read through Statistical Techniques for Network Security (cheap, only $160 on amazon)

Then fire up your favorite text editor and code a little, but utilize RapidMiner or Weka because, well, coding those algorithms is too easy.

Finally spend a couple hours tuning up the algorithms and then your all set.

Sarcasm aside, the steps above outlines an academically popular way to creatively solve a lot of hard problems in security.  I wish I could say I could do the above proficiently - maybe you can write a tool to do it!


Attacks via physical access to USB (DMA...?) I wonder if USB can be exploited by someone with physical access to a reasonably secured computer. For example a kiosk, or a laptop attached to a desk.

Obviously, the boot sequence should be secure (BIOS/UEFI set to "internal disk only" and password protected...). Also, mount options should be restricted with nodev,nosuid,noexec. Also, files should be analyzed by antivirus/antimalware. .. And so on.

I am really concerned about exploits like DMA attacks, where a user just has to plug in a USB device to extract information in memory.

Which features could be disabled to still allow mouse and keyboard but reduce the attack surface?

Before we start, a quick word about how USB works. A USB device connects to a piece of hardware inside the computer called the USB host controller. This decodes the complex USB protocol, which, much like a network protocol like TCP, contains packets, checksums, the equivalents of SYNs, ACKs, etc. The USB host controller decodes each individual connected USB device and presents it to the operating system, where it can interpret it however it wants (e.g. as a block device, or a mouse, or even a dialup modem, you name it). The USB controller itself connects to the PCH (which is like a relay station) over PCI. It's not a bulky PCI slot, but it's PCI nevertheless. The USB controller is what you see when you look at the output of lspci on your system and see mentions of USB. You probably have a few USB controllers, each connected over PCI to the PCH. The PCH in turn connects to the CPU. See this great Stack Exchange post that has a very good graphical description of USB controller anatomy.
Now let's break the possible types of attacks into three parts.
Intentional behavior
Most Linux distros auto-mount USB devices with filesystems, and some even have the ability to autorun, though this is rarely enabled by default. This was more a problem in the olden days of Windows, and never was really an issue in Linux. However, USB 3.1 does support DMA, so you might want to avoid that. I do believe it is disabled by default though, so it's not a massive risk. Just be aware that the USB controller allows it.
Exploiting software
There have been multiple instances of vulnerabilities in the partition table parsing code, where simply plugging in a USB stick can exploit the system by way of a specially designed but corrupt partition table. Though that's pretty rare (I am only aware of two that allowed for arbitrary code execution), vulnerabilities for auto-mounting filesystems are much more common, considering how incredibly complex filesystems are. They parse a huge amount of structures, and they prioritize performance above almost all else, so sanity checks are often not done unless they are necessary. This gives way to an increased number of vulnerabilities. But even if you aren't affected by any of those, there are plenty of vulnerabilities for your favorite desktop environment and how it manages displaying folder contents, such as thumbnail generation... Just recently there was a vulnerability in ffmpeg that allowed it to phone home to arbitrary servers, and before that, a vulnerability in libpng that allowed arbitrary code execution.
Exploiting hardware
This is by far the scariest and hardest to mitigate. While (most) USB protocols do not allow for DMA, and none allow for it by default, the USB controller is connected to the PCH over PCI, which has DMA abilities. The USB controller promises never to do evil, of course, and promises it will tell any mean USB devices to fsck off if they refuse to follow the protocol, but it is certainly possible for the controller to be hijacked by a malicious USB device which presents it with corrupt packets. Once it gains control of the protocol, it has full DMA and can do anything it wants. The only way to protect from this is to use your IOMMU to isolate the PCI device. There are several ways to do this, such as using Qubes OS which, while it has its share of shortcomings, is specifically designed to protect against hardware attacks such as this one. Or you could be creative. I went and made my own small bootable Linux distro which I use in combination with QEMU/KVM, a technology called VFIO, a driver called usbip, and a few custom scripts and programs which mitigate the issue. But if you rely on your IOMMU to protect you, just make sure it supports interrupt remapping. Otherwise it can be bypassed fairly easily and provides little security benefit.
USB 3.0 can be especially problematic. I'm not talking about 3.1 allowing DMA when the host says OK, but running outside the kernel. USB 3.0 runs as a binary blob in the BIOS, much like the Intel Management Engine. See this and this. It has a very large attack surface, adding to the already large surface area of the USB host controller hardware. You can disable it in many BIOSes, usually under a name like "xHCI controller". Doing this will effectively turn all 3.0 ports into 2.0 ports which decreases their speed, but it improves security a good bit. In terms of paranoid security, 1.0 is not good, 2.0 is bad, and 3.0 is a nightmare.
There is a kernel patch called grsecurity which has a huge number of security features that vastly increases the security of the Linux kernel. One of the security features is "deny access to new USB devices", which does just as it sounds. Either after you toggle a one-way setting, or after boot, all new USB devices will no longer be allowed access. All the complex, potentially vulnerable kernel code which deals with USB devices is disabled. It will completely mitigate the first two issues, but unfortunately does nothing at all to mitigate the third. Even compiling a custom kernel and removing the USB drivers does not mitigate the third.


How did the Facebook Originull vulnerablity of Access-Control-Allow-Origin: null allow cross-origin access? Recently, a vulnerability in Facebook's messenger app which allowed attacks to access a users private messages via cross-origin AJAX was patched and disclosed.

  Simple Bug allows Hackers to Read all your Private Facebook Messenger Chats

  The root of this issue was misconfigured cross-origin header implementation on Facebook's chat server domain, which allowed an attacker to bypass origin checks and access Facebook messages from an external website.

The name of "Originull" and screenshot seem to indicate the problem is the following header:

Access-Control-Allow-Origin: null

But this leaves me wondering, how exactly a value of null leads to a vulnerability. This doesn't look like a valid origin, unless you were to somehow visit a website from the domain of null (actually, it would need to be http://null or https://null, as the protocol would need to be included).

I checked, and null is not actually an allowed value in the same way * is, in Chrome or Firefox.

  XMLHttpRequest cannot load http://other.localhost/ajax.php. The 'Access-Control-Allow-Origin' header contains the invalid value 'null'. Origin 'http://localhost' is therefore not allowed access.

(Using a value of * does work however, so clearly just being null is not enough for arbitrary pages to access these resources.)

Is there some feature or bug in browsers that read null as *? Or some feature in browsers, like pages opened by a data URI, that allow matching to null? How does this vulnerability work?

I'm Ysrael and I'm the researcher that found this vulnerability.

Let's divide your question into 2 parts:
A. How did the Origin of the browser become null?
B. How the null Origin affect Facebook servers?

Let's start with A.
The Origin is part of the CORS mechanism and it is intended to tell the server where the request comes from.
When the server gets the request, the server can decide to allow this Origin to receive the response.
One of the ways to bypass this protection was to find an Open-Redirect within one of the pages, and then to direct the user to dataURI schema.
In the past, dataURI received the previous Origin because there was no other Origin to give him.
As a security improvement, the modern browser sets the Origin to null so the XHR requests from this dataURI page won't have the proper Origin.
In Chrome, this is the situation in any case, and in Firefox it happens only when the page refreshed via meta tag to dataURI.

So this is how the Origin became null.

The 'Originull' attack uses this behavior in order to bypass security checks that are based on the Origin, because most of the time, the programmers won't think of null as the value in this field.

Now let's get to part B. How this affected Facebook.

Facebook uses Access-Control-Allow-Origin on its Messenger servers, because they use a different sub-domain.

Most likely, the Messenger sub-domain has a security filter on the entrance, and then the requests are passed to the internal server that responds to the users.
When the server wanted to respond, it took the value from the request's Origin and returned it on the Access-Control-Allow-Origin header.
This development design allows Facebook to keep up the allowed Origins in one place only.

The messenger sub-domain also allows regular GET requests.
Regular GET requests didn't have an Origin header at all.
In many development languages, a non-exist Header returns the value null.

So, the filter has a condition that allows null to pass (so the GET requests will pass correctly), and the server takes the value that it receives in the request's Origin header (null) and returns it to the client in the Access-Control-Allow-Origin header.

Simple, right? ;)

You can find the technical details and screen shots in the full-disclosure document on BusSec's web site at:
https://www.bugsec.com/wp-content/uploads/2016/12/Blog-Post-BugSec-Cynet-Facebook-Originull.pdf


Is there an estimation of the number of zero-days out there? A zero day vulnerability refers to a hole in software that is unknown
to the vendor.

Since, zero day vulnerabilities are unknown can any estimation of amounts be made? What are possible scenarios to estimate the amount of zero-days? For example, based on experience with buying/selling zero day vulnerabilities.
I wonder how many undiscovered bugs there approximately are in the world and how many known zero day vulnerabilities with exploits there are approximately.

Vulnerabilities, in general, exist before they are found by researchers so the number already in existence but not yet known could be very high. As for known Vulnerabilities that would constitute Zero-Days where an exploit exists but are still held privately by a few people or organizations, there is really no way to know because too many of these organizations are very secretive for obvious reasons. It is too hard to speculate how much effort has been put into finding Zero-Days globally much less how productive those people or organizations have been at doing so.

That said the following Rand Corporation paper has a lot of very relevant information to your question.

Zero Days, Thousands of Nights "The Life and Times of Zero-Day Vulnerabilities and Their Exploits
http://www.rand.org/content/dam/rand/pubs/research_reports/RR1700/RR1751/RAND_RR1751.pdf

Something to also keep in mind is there has been a lot of advances in fuzzing technology in the last few years which may make finding new zero-days easier for attackers.


Capturing and decrypting my own SSL traffic When I use browser or wget to access another site, some sites will only use HTTPS / SSL automatically. When a site doesn't provide content without encryption, how do I capture what my computer sends for analysis? Is it possible for me to disable SSL with my browser or wget?

I'm running Linux, and would like to use tcpdump or other Linux tools for this.

Tools such as this SSL MITM proxy from Stanford can automatically generate certificates and provide an SSL-to-SSL cutover. You'll need to set the key used by the proxy to be trusted by your browser, but that will provide you with the ability to see the cleartext traffic that is leaving from your machine.

While you can try to rewrite any HTTPS redirect requests to have HTTP, many website that provide HTTPS support will only provide content over the encrypted channel; the unencrypted channel provides nothing but redirects.

Moxie Marlinspike's SSL Strip will probably also fulfill your goal by transiting the HTTPS traffic, but only speaking with your client using HTTP and rewriting redirects.


How do I verify exactly which cipher suite is in use for this Remote Desktop session? You can configure Windows to use only certain cipher suites during things like Remote Desktop sessions.  Cipher suites such as RC4 56 bit, RC4 128 bit, Triple DES 168 bit, etc.

SSL/TLS is not in play here so I'm talking about RDP encryption.

You can see what I'm talking about here.

I thought to run a packet capture using Wireshark or Network Monitor while I connected to a computer across the network, but I cannot see anywhere in the packet capture the bits I need to verify exactly which cipher suite it is using.

Enable SCHANNEL logging;

http://support.microsoft.com/kb/260729

The following will log everything;

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000007

You will then have events in the SYSTEM log for example;

An SSL client handshake completed successfully. The negotiated cryptographic parameters are as follows.

Protocol: TLS 1.0
   CipherSuite: 0x2f
   Exchange strength: 1024

Google the resulting cipher suite.

FAWC

When using Elliptic Curve certificates you will also get something like the following as the certificates are exchanged;

An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.

Protocol: TLS 1.0
   CipherSuite: 0xc009
   Exchange strength: 256


What does this sudo -l output mean and can this be priv. escalated? I am trying to do priviledge escalation of a linux box.
My sudo -l output shows the following :

www-data@box:/scripts$ sudo -l
sudo -l
Matching Defaults entries for www-data on box:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User www-data may run the following commands on box:
    (scriptmanager : scriptmanager) NOPASSWD: ALL

What does the (scriptmanager : scriptmanager) mean?

And in one of the directories that I listed, it showed :

www-data@box:/scripts$ ls -l
ls -l
total 20
-rw-r--r-- 1 scriptmanager scriptmanager  88 Feb  8 09:11 dek.py
-rw-r--r-- 1 root          root            0 Feb  8 10:11 dik.py
-rw-r--r-- 1 www-data      www-data      129 Feb  8 09:25 mmm.py
-rw-r--r-- 1 scriptmanager scriptmanager  58 Dec  4 17:03 test.py
-rw-r--r-- 1 root          root           12 Feb  8 10:11 test.txt
-rw-r--r-- 1 www-data      www-data       85 Feb  8 10:08 tmp.py

Is there a way to priviledge escalate to a root shell? I have limited user shell without the password.

(scriptmanager : scriptmanager) NOPASSWD: ALL

means that you can run any command as scriptmanager, and optionally set your group to scriptmanager when doing so.
You won't need to provide a password when doing so.
The scriptmanager user (or group) may or may not have the privileges you ultimately want.


Handling sensitive data for a web application I'll save you the detail of the issues, but do let me know if you need any additional info that I'm not mentioning here.

The basic set up is that I have a web application, and on the browser the user will enter some relatively sensitive information that will be transmitted to the server through https. Unlike passwords for logins, these information submitted by the users will need to be available/readable to the users in the future, and hence reversibly encrypted.

I have found a few relevant posts, but I am not sure if I completely understand them. My initial thought was as follows:

Ask the user to submit a passcode along with their sensitive info.
On the server side, I encrypt the sensitive info using their passcode through AES etc.
I store the encrypted info in my database, and discard the passcode.
When the user needs to see the sensitive info, I ask them to type in the passcode again, which is then sent to the server.
Once I get the passcode, I use it to decrypt the info from my database, and send the decrypted info back to the browser.

Bottom line is that, I never store the passcode used as the key for the encryption. Now this is going to sound naive and broad, but can someone give me an idea of whether/how secure this procedure would be? My guess is that, since the key is nowhere to be found on the server, the info is as secure/insecure as the AES encryption method itself.

How to encypt sensitive data in database of a web app?

I've been reading answer from the above link, which involves a several additional layers of encryption. I can probably implement it, but are those additional steps necessary for my purpose? And if so, how did those steps make it more secure than what I have described above? For example, worst-case scenario, if the entire server is compromised, would this latter method be more desirable?

Thanks!

I think one main problem for the first approach is that once the passcode is lost by the user, there is no way at all to ever recover it (without brute-force). Depending on the kind of information that might be a requirement though.

So coming to the linked article it will explain how it solves that problem.
It has more comfort and lets you implement it in the hopefully already existing change password algorithm to always generate a new KEK and re-encrypt the DEK.
The password is more unlikely to be forgotten


Which hard disk encryptions schemes are tied to the original hardware? When using a laptop, an encrypted HD/SSD can be an important security measure. However, laptops are prone to accidents (fluid spills, dropping on the floor, etc) that may mandate some or all of the components to be replaced.

Are there hard disk encryption schemes that tie the encryption key to other hardware than the HD?

Meaning the drive would be unreadable when it's plugged into a machine other than the (destroyed) original one. Just to avoid them when using a laptop ;-)

None that I know of. The standard for disk encryption is TrueCrypt, which accepts a password, key files, and smart cards as authentication credentials.

So, at worst, you could use your key files if you put them on a single drive and it fails. Of course, that should be a moot point since you're doing regular backups, right? ;)


Are there any risks involved with plugging smartphones into Windows 7-10 computer's USB ports? When you plug a smartphone into a USB port on a Windows 7-10 computer, often a small message box pops up on the Windows device indicating that drivers are being installed.  This happens automatically without any user intervention.
As opposed to a similar question I apparently asked over 4 years ago (oh dear), for this question I'm interested in drivers that are installed automatically on the Windows box without any user interaction.
What is the source of those drivers?  Do they ever come from the phone itself?  Are there any security risks involved with this?  Specifically, I'm wondering if there is any risk of plugging in phones manufactured by companies with questionable reputations.
Please note that for this question I'm concerned about the security of the Windows computer, and not the smartphone.

For automatic driver installation specifically:
Windows installs drivers automatically if they are in-box (that is, included with the OS), or if they are on Windows Update and you have the optional (but I think enabled-by-default) feature to search Windows Update for needed drivers. In both cases, these drivers will be "blessed" by Microsoft with a WHQL (Windows Hardware Qualification Labs) signature - this is necessary to install a driver in 64-bit Windows at all, unless you mess with the boot parameters - meaning that they have been tested for some level of correctness and also come from a known, verified vendor.
Note that WHQL signatures, and even in-box or WU distribution, do not guarantee that the driver has no security vulnerabilities. Driver security is a complicated topic that lots of hardware vendors make mistakes on - there was a high-profile case recently where NVIDIA's graphics driver was found to have some serious vulnerabilities and they pushed an urgent patch - and of course drivers have such a privileged position that vulnerabilities in them can compromise the entire system. On the other hand, if a driver isn't loaded, it doesn't matter how vulnerable it is, and loading a driver requires Admin privileges so low-privilege malware can't just load a known-vulnerable driver to gain an EoP vector.
WHQL also doesn't guarantee the stability of the driver, beyond for basic steps like loading and unloading. Driver instability has long been a leading cause of kernel panics (Blue Screens of Death), though it's unlikely for any WHQL driver to cause a BSOD just from plugging in its hardware.
Also, depending on the phone and how it's configured, the phone itself might not need its own driver. A phone that is connected in USB Mass Storage (UMS) or Media Transfer Protocol (MTP) modes will use a generic Windows driver that supports such modes. These drivers are written by Microsoft and subjected to extensive testing (though of course there can still be bugs).
Do note that, for "active" multi-function devices like smartphones, there may be many different drivers, as the device can present itself as any kind of USB device or even as a hub (which has its own generic driver) with many different devices connected to it.

Outside of drivers specifically, smartphones could also be used for other attacks. There are many kinds of malicious USB devices out there, such as "Rubber Duckies" that type attacker-chosen keystrokes at superhuman speed, or even a "USB Killer" that uses a large power surge to destroy the USB port and possibly other components. Plugging in unknown, untrusted USB devices is risky behavior, and that includes phones!


What is web application security best practice for HTTP Get request? If I have web application GET URL which gives me details of particular user. What is more secure / which is good practice?

eg.

www.xyz.com/user?id=10

or

www.xyz.com/user?fname="abc"&lname="lmn"

Or is anything else preferred?

Which points should be considered?

I have a page with a list of users, on which clicking the user name should lead to that particular user details.

Since GET request are more prone to be saved in various logs, it is considered unsafe to place private or confidential information in them.

Using an ID is perfectly fine since it is anonymous data. If your user ID is not a surrogate key, then you should create a new one and use it for externally identify the user.


Storing password in Java application What is best secure way to store passwords in Java web application?

I am not talking about password to the DB, so it must be stored in de-cryptable way. It’s cloud environment and I need to protect DB credentials even if my VM with web application get compromised.

What are my options? If to store it encrypted, where/how should I store encryption keys?

The best way to store Passwords in Java applications , if you are running it on Windows bases systems is to use DPAPI from Microsoft, which uses the user's windows creds to encrypt the passwords. http://msdn.microsoft.com/en-us/library/ms995355.aspx.

There is also a Java wrapper for your convenience http://jdpapi.sourceforge.net/

Since Windows will manage your keys, you don't have to manage keys yourself. In Java, never think about writing your own mechanism to manage keys and store passwords. It is simply not secure because, any one having access to your .jar file can easily reverse engineer to the source code files and obtain your mechanism. CryptProtectData() is the way to go


Is it normal to receive working SMS verification code from strange number? Here is a sample SMS that usually I trust:

The sender is in a text format and there is an information saying the sender does not support replies.

When I tried to login, I received verification code from a different number:

Now, the sender is a normal phone number.  I can even reply to the number. There is a few strange characters in the prefix.  Also, there is a wrong spelling: "confirm you (should be your) number".  This SMS raises my suspicion. While the activation code is working, how can I be sure if the SMS is really send by the provider and not by someone in-the-middle?

Yes. The use of SMS for 2FA is very price sensitive (it's a commodity market racing to the bottom). The use and registration of alphanumeric sender ids (like "UBER") costs money and time (you have to get the contracts). But if one just wants the content delivered to the handsets, one uses the lowest bidder for delivery who will in the end use some numbers (can be even throw-away burner phones) as the last hop to deliver the SMS to the handset.

The scrambling of the content can also be intentional: Of course the telcos want the customers to use their pricey services, so the try to detect and block traffic from cheap numbers. One way to get around theses blocks is subtly altering the content.

I work at an SMS aggregator who develops 2FA, delivers SMS for 2FA, uses SMS routes, and has heard of content scrambling.


Evil AP with known WPA2 password So I have been playing around with the aircrack-ng suite and beef a mitmf.
Until now I have been able to host an Evil Twin with DHCP server and providing internet access to connected clients while capturing all their packets.

Now imagine there is an AP that uses WPA2 encryption, but I already know the password to it.
I can run airbase-ng with the -W and -Z flags and copy the encryption methods used by the original (real) AP. The thing is that I cannot provide a password for, so when others get deauthenticated from the real one they are unable to access the internet via my Evil Twin.

To make it clear, I don't want the WPA2 password, I already have it, I just want to perfectly spoof the other AP even it's WPA2 password so devices are able to connect to me automatically. (Basically let airbase-ng complete the 4 way handshake)

Is that possible with the air-ng tools? I'm running kali linux by the way.

From Airbase-ng site, yes you can.
You need the following command: airbase-ng -c 9 -e teddy -z 2 -W 1 rausb0 where:

-c 9 specifies the channel
-e teddy filters a single SSID
-z 2 specifies TKIP
-W 1 set WEP flag because some clients get confused without it.
rausb0 specifies the wireless interface to use

I tired to achieve what you're trying to do once, and the problem is within the encryption protocol. You need to make sure that you're using the correct one. TKIP or CCMP.


Code-signing application from different locations In our company, one of the software group is using a certificate from a trusted provider to sign their drivers manually on their local machine. My group wants to start to sign our installers and some administrator tools and we would like to use the same certificate.

The problem is each group is using its own build machine where the signing will need to be done.

I'm not an expert with certification and I'm not sure what is the best approach and if it is possible to do it:

1) Install the certificate on each build machine. I guess it is not recommanded because your certificate could be compromise more easily since it is located at more than one place.
2) Install the certificate on a server and each build machine call it to sign their own binaries.

or something else?

Note: Our infrastructure is on Windows.

The important part is the private key to which the certificate is linked. Unfortunately, some widely deployed documentations get it wrong and call "certificate" what really is the union of the certificate itself (which contains the public key and is entirely public) and the corresponding private key (which had better not be public, of course).

In order to keep the private key private, it is best not to copy it in many places. When a private key "travels" between computers, it is normally as a PKCS#12 archive (previously known as "PFX"), which contains the certificate and the private key, and is password-protected. The entropy of this password is crucial for the security of this transit, but, of course, this protects only the key as it is transferred. You are right: the more a private key is copied, the more vulnerable to theft it becomes.

The normal way of doing this is the following:

Each build machine has its own development certificate. Development certificates are certificates which you generate yourself, with a custom CA (which can be some crude usage of the OpenSSL command-line tool). Test machines, on which development is performed, are configured to accept this custom CA as trusted (or maybe signature checks are deactivated altogether).
For production releases, the binaries which are to be signed are transported to a specific, protected machine which contains the real signature key (the one corresponding to the certificate that you bought from the "trusted provider"). Releases don't occur often, so this manual procedure should be acceptable.

Having a free-for-all signature system, accessible and routinely accessed by developers, looks somewhat dangerous to me. A signature with a key which is trusted by third parties is a responsibility: it makes you liable. You should strive to sign things with that key at rarely as possible, i.e. only for releases.


How was DDoS attack on Dyn made? https://krebsonsecurity.com/2016/10/ddos-on-dyn-impacts-twitter-spotify-reddit/#more-36727

A DDoS attack on Dyn, on 21st Oct 2016, caused outages for Twitter, SoundCloud, Spotify, Reddit, etc. on the East Coast of USA.

How was the attack carried out, its type, and other details about it?

Ecuador's government confirms that they cut Julian Assange's Internet connection, after another batch of email exchanges (involves Ms Hillary Clinton) was leaked by Wikileaks, at its embassy in London.
As per news, the DDoS attack was generated to take revenge for this.

Wikileaks requested the attackers to stop the DDoS attack immediately.

Type of attack
Latest reports indicate that the DDoS attack on Dyn infrastructure (particularly DNS servers) was generated using infected IoT devices (like CCTVs, WebCam and others).
The source code of one such malware named Mirai was released on the Internet recently. It is speculated that this malware was used for generating the attack.


Best archive format for cryptographic signing? I want to sign a whole directory of files using GPG, and that entails creating an archive or compressed file, since GPG can only sign a file, not a directory. However, I imagine that some archive formats may contain some kind of user-agent-specific data or timestamps or nonces that may make cryptographic signatures non-reproducible.

My question: is there an archive format, such as zip or tar, that does not vary at all, such that the cryptographic signatures generated by one will be the same across all computers that create a similar archive using the same inputs?

that entails creating an archive or compressed file

That premise is not necessarily true. You don't necessarily need to create an archive to cryptographically sign multiple files. I'll give a few examples.

Manifest file

You can sign a file that contains a list of file hashes, this file is usually called a "manifest". The signature on the manifest will cover all the hashed files. Using a manifest instead of an archive has the advantage that you can add and remove files from your directory without completely invalidating the signature; other people can modify two files and prove that they only modified the two files as only the hash of two files changed from your original version. Essentially, you sign the directory using this kind of script:

find $directory -type f -print0 | sort -z | xargs --null sha256sum | gpg2 --clearsign > manifest.txt

This is more or less the strategy that is used in a JAR file (though jarsigner uses x509 certificate instead of OpenPGP).

Signed git repository

You can create a git repository and cryptographically sign the files using gpg-signed commits/tags.

$ git init

$ git add .
$ git commit --gpg-sign -m "Version 1"

or

$ git tag --sign version-1

Reproducible tar file

If you insist on creating an archive, you can make a reproducible tar file. These are much more complex because an archive can contain metadata, but fortunately the tar program have many arguments that allows you to select which metadata you want to preserve. With an archive, you have a lot of flexibility on whether or not you want to sign permissions, modification times (which may be necessary if you later want to use tools like make), and other metadata. You can create a reproducible tar like so:

tar --sort=name \
  --mtime="0" \
  --owner=0 --group=0 --numeric-owner \
  -cf file.tar $directory
gpg2 --sign file.tar

For more about creating reproducible tar file, I would suggest reading this article.


What is a good enough salt for a SaltedHash? Since I'm hashing all passwords with each their own salt, is there a benefit to the salt being really random, or would an incremental counter or a guid be good enough? Also, is there a benefit of having a bigger salt vs. a smaller salt?

EDIT:
Since it is established that hashes shouldn't be too small: What is a sufficient size of a salt? Will a guid (16 bytes) do?

The unique purpose of the salt is to be unique: no two hashed passwords shall use the same salt value. This is meant to prevent cost sharing such as precomputed hash tables.

Uniqueness should be worldwide. For instance, suppose that you used a simple counter as a salt. Correspondingly, the value "1" will be used as salt for the first created account, presumably the one for the server administrator. This will be true for all installed instances of that server. This makes it worthwhile to precompute a big table (e.g. a rainbow table) of potential hashed passwords using "1" as salt, because that table could be used to attack the administrator password on all servers which use that software. The word to meditate here is "worthwhile".

Since server-wide uniqueness is not enough, a counter will not be sufficient; the user name is not a good salt either (user names are unique on a given server, but there are many 'Bob', 'Joe' and 'DarkLord42' out there). An UUID (GUID) is supposed to do the trick. You can also use a strong uniform pseudorandom generator (/dev/urandom, CryptGenRandom(), java.security.SecureRandom... depending on the platform you use) and get enough random bytes from it so that risks of reusing a salt value are sufficiently small; 16 bytes are enough for that. Using randomness is the "robust way" because it yields uniqueness with a sufficiently high probability, without having to rely on world-wide conventions.


What do I do if I catch someone doing a physical pentest? This question was primarily inspired by this (related) question, but is about the other side of the equation.

I'm a security engineer at Medium Sized Company, Inc. We recently hired John for a penetration test (unbeknownst to me). John successfully got into our building and made it all the way up to our floor. He got someone to let him in and gained access to a relatively secure area.

Unfortunately for John, his presence in the secure area triggered an alarm which dispatched me to investigate. I found John in our server room, where he was about to plug something in to one of our network switches.

I managed to stop him before he connected his computer to our switch, and demanded to know what he was doing there in a secure area. He presented me with a Permission to Attack slip which did not check out, followed by a real Permission to Attack slip that was confirmed with the relevant party.

Right now, I have a hacker sitting handcuffed to a chair in the server room, not allowed to leave my sight until I know what to do with them.

So, what do I do with them? There are a few options I can think of:

Escort them out of the building,
Just politely tell them to leave the premises as the penetration test has concluded,
Let them keep doing whatever it was they're doing and hope our NOC catches them too

My company doesn't have any policy guidelines I should follow and the person on the PtA form doesn't know either, so I'd like to know what's considered the best-practice in a situation like this.

Start by releasing him from those handcuffs. If the permission to attack slip did truly checkout, then John is not a criminal. He is simply a poor guy hired by your company trying to do his job, and has now found himself handcuffed to a chair. As such, I have my doubts he would try to run or attack anyone, so it should be safe to release him.

As mentioned in the comments, John's cover is blown. Unless the rules of engagement state that he should continue with his pentest, there is nothing left for him to do there. I would escort him out of the building instead of asking him politely to leave, as trusting him to leave the premises seems like a poor security control and this is a test of your organization's security, after all.

The fact that he was caught is a good sign. Even though he was able to enter the server room, the organization's security has held up well in this instance by stopping John from planting what is probably a backdoor device. So if anyone finds themselves here, good job. After this incident, I would get things worked out on how fix this lapse of information in the future. I would think the person on the PtA form should know what to do, given that he is listed on the PtA form, and as schroeder mentioned, this should have also been covered in the preliminary engagement meeting for those who were in attendance. Someone should know the answer to this question, and it should be straightforward to contact them. If it isn't, I would get in contact with the head of security and ask them this same question.


Secure USB stick recommendation I've read a lot on this site about how USB sticks are inherently (I assume) insecure. There are analyses about how just by plugging it in to your laptop might initialize some program to be run without you knowing, and so can install malware on your computer.

With this in mind, I am wondering if it is even a good idea to buy a USB stick, and if so, what are some examples of relatively secure options.

USB sticks you own and control bought from a trusted source are fine. Trusted source being a known retailer or brand.
Its picking up a random one off the street or a receiving one from an untrusted source that introduces risk.

Think of it as software if you buy an application from a trusted source you run it on your machine - if you grab something from a torrent well roll the dice.

If you are really worried buy one and configure your system to only allow USB storage from that particular device. Windows you can do this via group policy.


Can a signed mobile application be altered? If a signed mobile application is modified, then its signature and checksum become invalid.

Is it possible to forge a new, valid signature?

In theory, yes, it is possible to make an arbitrary application and pad it such that the hash matches, but in reality, this is extremely difficult to impossible unless the hash used has known weaknesses.

A good hash works because it has a large number of possible outputs and it is difficult to predict the output from the input.  As long as the hash succeeds at these two criteria, an attacker would need to brute force a crack by making changes to their program until they can get a hash collision.  Since the collision space is so large on modern secure hashes, it would take impractically long times (centuries or longer) to generate a hash collision even while spending government levels of computing on generating a collision.

The odds for the attacker improve a little if they are trying to produce a "good version" and a "bad version" that match intentionally as they can "meet in the middle" by making a bunch of different good builds and a bunch of different bad ones and just need any two of them to match, but it's still highly impractical due to the amount of computation required to even manage that with secure modern cryptographic hashes.


Can my GSM network operator figure out the name of the Wi-Fi access point I am connected to? I recently saw a film where the police were able to locate where the criminal was because the GSM network operator knew the name of the Wi-Fi access point the phone of the criminal was connected to when a SMS text message was sent from the phone. Is this realistic? Does a mobile phone broadcast the name of the Wi-Fi access point to which the phone is connected?

Is it realistic? Yes and no.

UPDATE Does your mobile phone automatically tell your mobile operator the name of your wi-fi access point? no.

TL;DR you most likely have a smart phone with several apps installed, and chances are that several of those apps already "phone home" in the clear lots of information about you, including your wi-fi access point name. So a mobile operator would just have to sniff your traffic and you won't even notice.

That said, as 99% of the movies out there, technical realism is missing and if there is any left it's grossly over-simplified to move on with the plot. See for example this XKCD comic:

Furthermore, your mobile operator can push content to your phone. Non-smartphones can receive instructions to turn on their microphones and become bugs. Smartphones, on the other hand, have many more vulnerabilities as you might be already aware. Often a smartphone comes with a bunch of pre-installed apps from the manufacturer, and planned obsolescence pretty much guarantees that old models "re-branded" will not receive any security updates after a short lifetime, in the hope that you (the customer) will just buy a new phone. The margins for a phone manufacturer are so low that it's not worth pushing it.

Now, once your phone is pwned it would be trivial to execute code to determine the wi-fi access point you're connected to.

I haven't provided any links here on purpose: see if you can find more information on this for yourself. It will be a learning experience.


How to ensure that files uploaded by users do not contain any XSS code I have been working on providing the security related to the XSS attacks. My website only allows following mime-types:

XML, CSV, HTML, PLAIN, VND_WAP_WML, APPLICATION_ZIP, APPLICATION_PDF, APPLICATION_VND_FDF, APPLICATION_MS_WORD, APPLICATION_OCTET_STREAM, APPLICATION_VND_MS_POWERPOINT, APPLICATION_X_VISIO, IMAGE_GIF, IMAGE_PNG, IMAGE_TIF, APPLICATION_VND_MS_OUTLOOK, APPLICATION_DOWNLOAD, APPLICATION_JSON

I have sanitized HTML files using antiSamy. How can I ensure that the data in the files is safe before uploading the data to database, and prevent persistent XSS attacks?

You can't, really.

You can reduce the chances of content-sniffing running HTML by serving files with a X-Content-Type-Options: nosniff header, and try to avoid them being treated as HTML pages by serving with Content-Disposition: attachment, but still you have older browsers to worry about, and browser plugins. (For example Java's broken SOP and Flash's crossdomain XML sniffing.)

Best workaround if you have to accept user-uploaded files is to serve them from a separate domain, so that any XSS attack can't compromise the main site.


Safe mobile browsing What actions can I take to make web browsing on mobile phone (android) as safe as possible? My main concern are sites that would install malware (has happened before on desktop computer). On a computer, I would run browser in a sandbox environment (e.g. Sandboxie). Are there similar alternatives for mobile phones? Or are mobile environments more completely sandboxed by nature?

Installing malware through websites is not as common as you seem to think. The malicious website needs to exploit a vulnerability in your browser which permits to get root access (quite uncommon).
So, as far as your browser is up to date, only the 0days (rare) could affect you.
But, even with less privilege, the malicious website could still tamper the behavior of your browser (spying you, insert scripts in the visited pages, ...).
Sandboxes can be a partial answer to this threat because they focus on isolating a process from the rest of the system (to avoid a malware spraying everywhere). They do are present in Android but they are not the ultimate protection.
Another way to protect you is to disable script (javascript mainly) in the setting of your browser.
But many websites will be broken as client side scripting is now a huge part of the Web 2.0.
Security experts, who want to keep their computer safe, rely on up to date Linux (android is Linux-based) and avoiding crap websites with malvertising (like porn, download, buzznews, ...).
It is less overkill than disabling the scripts.
Maybe take a look at the brave browser which is designed to limit the websites capabilities on your browser.


Which part of this encoded Argon2 hash is the salt? I was reading the post Is it safe/wise to store a salt in the same field as the hashed password?:

$argon2i$v=19$m=65536,t=3,p=1$YOtX2//7NoD/owm8RZ8llw==$fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE=
My understanding is that everything prior to p= are parameters, the body of the p= is the salt, and the last part is the hashed password."

I do not understand the highlighted part. I thought$ slices variant, version, parameters, salt and hash, so that:

p (parallelism parameter) = 1
salt = YOtX2//7NoD/owm8RZ8llw==
hash = fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE=

Am I correct in identifying salt and hash here?

$argon2i$v=19$m=65536,t=3,p=1$YOtX2//7NoD/owm8RZ8llw==$fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE=

argon2{i} three types i,d,id

Argon2d is faster and uses data-depending memory access. Data dependency immediately enables side-channel. This is suitable for cryptocurrencies and applications with no threats from side-channel attacks.

Argon2i uses data-independent memory access and this is preferred for password hashing and password-based key derivations.

Argon2id In the first half of the first iteration works as Argon2i and for the rest works as the Argon2d. This enables both side-channel protection and time-memory trade-off.
And if you don't know the difference or you consider side-channel attacks as viable threat use Argon2id.
Better advice Use Argon2id unless you know you have a good reason to use any other mode by MechMK1

v=19 - v for version, here version is 19

m=65536 - m is the integer representing the variable memory cost,  in kibibytes here 65536 kibibytes.

t - is the integer representing the variable timing cost in linear iteratrion, here 3.

p=1 - p is the parallelization mechanism to control the amount of parellization

salt - here YOtX2//7NoD/owm8RZ8llw==

digest - here fPn4sPgkFAuBJo3M3UzcGss3dJysxLJdPdvojRF20ZE=

Split with $ sign, the last token is the digest and the one before the last token is the salt.

Note: Argon2 is a key derivation function that was selected as the winner of the Password Hashing Competition in July 2015. The Specs paper;

Argon2: the memory-hard function for password hashing and other
applications


In what situations can element.setAttribute allow XSS? Burp has identified a potential DOM XSS vulnerability:

  The application may be vulnerable to DOM-based cross-site scripting. Data is read from window.location.href and passed to the 'setAttribute()' function of a DOM element

In this example, the vulnerable code is like (I can't include the actual original for confidentiality):

var thing = windows.location.href;
...
element.setAttribute("fill", thing);

The OWASP DOM XSS Cheat Sheet says "JavaScript Escape Before Inserting Untrusted Data into HTML Attribute Subcontext within the Execution Context". I'm not quite sure what they mean by execution context.

Doing some quick tests (in Chrome), this is vulnerable:

document.getElementById("bob").setAttribute("onclick", "alert(1)");

But this is not:

document.getElementById("bob").setAttribute("fill", "&quot; onclick=&quot;alert(1)");

Given all that, I feel Burp has reported a false positive. But I worry I may have missed something, so further input would be appreciated.

I am only interested if this is exploitable in recent browsers. I'm not interested in "it's not best practice" or "exploitable in IE 4 on a Mac".

setAttribute() is safe in that it does nothing more than setting the attribute's value. Even by using special characters in the string you cannot inject an additional attribute (as you attempted in your third snippet), let alone escape the HTML tag.

Some attributes are dangerous for some elements.  As you demonstrated, on* attributes are vulnerable because they let you specify script event handlers. Similarly, src and srcdoc are dangerous on <iframe> elements, etc.

The technique of injecting JS via url() as proposed by @Anders has worked in the past for CSS attributes but is not possible anymore in major browsers. Back then, a payload such as <rect fill="url('javascript:alert(1)')"/> could have worked. That might also be the reason why Burp flags it as a potential vulnerability. It's not an attack vector in recent browsers, though.


Why the symmetric key is added to the message? Yesterday in my class we learnt how to send a message from Alice to Bob with
the achieved goals of confidentiality, integrity and authenticity.
In order to have a better performance we use a hybrid method with a symmetric and an asymmetric key.

Alice's and Bob's private Keys are signed by a Certification Authority (CA) -> Authenticity

The goal of integrity is assured thanks to the hash:

h = hash(M)

Confidentiality is used assured thanks to the usage of a symmetric key only
known to Alice and Bob which was exchanged thanks to their asymmetric keys.

This all results in the following message - which Alice sends to Bob:

# public keys
K_A_E = public_key_Alice
K_B_E = public_key_Bob

K_B_E and K_A_E are signed by a CA.

# private keys
K_A_D = private_key_Alice

M = "our secret message"
h = hash(M)

K_AB = the_symmetric_key

this results in the message:
{K_AB}**K_B_E {{h}**K_A_D, M}**K_AB

I don't understand why it is necessary to start the message with {K_AB}**K_B_E.

* Why it is necessary to prepend the symmetric key K_AB at the beginning of the message?

* Is this symmetric key added to every message sent between Alice and Bob?

* Our lecturer mentioned that this way of encryption is used in OpenPGP. So does OpenPGP create a new symmetric key for every message?

To answer your questions:

{K_AB}**K_B_E is prepended to the message so that the receiver has the symmetric key to decrypt the message. Because the key K_B_E is used only Bob can decrypt the symmetric key and only he can therefore read the message.

The next is the hash {h} which is encrypted/signed by the key K_A_D. I assume that K_A_D is the private key of Alice, so this is the signature of the message.

The symmetric key is created newly for each message by the sender. And the sender has to send the key for decryption purposes to the receiver. Therefore the key is prepended (asymmetrically encrypted) to each message.

Yes, GPG and OpenPGP use this scheme.

As an extension:

I can prepend multiple (asymmetrically) encrypted keys to the message so that I can send the message to multiple receivers.

If I use a pre-shared key then I have to send the message either multiple times or have to share the symmetric key with multiple persons. This would make this scheme insecure. That's the reason why I create a new symmetric key for each message.

Also note that GPG/OpenPGP do not use a CA but create a Web of Trust to authenticate all other participants.