Possible attack vectors for a web site scraper I’ve written a little utility that, given a web site address, goes and gets some metadata from the site.  My ultimate goal here is to use this inside a web site that allows users to enter a site, and then this utility goes and gets some information: title, URL, and description.

I’m looking specifically at certain tags within the HTML, and I’m encoding the return data, so I believe I’ll be safe from XSS attacks.  However, I wonder if there are any other attack vectors that this leaves me open to.

What you're describing is a sort of proxy that returns basic information from an external website. I don't think it's a weird question at all, and I know of a couple of attack scenarios.

Your design practially allows SSRF (Server-Side Request Forgery) by design. This doesn't have to be a big deal, but can have serious consequences. For example, if you run your application in AWS, one can call the AWS meta-data endpoint, which in some cases can grant an attacker temporary access keys to parts of your AWS environment.

SSRF can also be used to access your internal network, the server's loopback interface, and other endpoints that your server is whitelisted for. You've got to make sure to blacklist internal addresses (I would resolve the domain and parse the IP address to match certain ranges). And you've got to block the AWS meta-data endpoint when using AWS.

Can users enter a full URL? Ensure that they can't use different schemas, like file:// or smb://, or they might read local files from your server. Also, note that if you return the URL on your website, they might use a javascript:-schema to perform XSS when the URL is clicked.

Are you using an XML parser to parse the external HTML? If so, make sure you're not vulnerable to XXE and secure your XML parser by not allowing External Entities.

Needless to say I hope you don't append your user's input into some system command, like curl -s [URL], since that would allow for Command Injection. It's so stupid that I don't like to mention it, but I've seen people do it.

Note that showing data from the external website in JavaScript-context or in HTML attributes requires different encoding than HTML encoding.

The rest depends on your application's architecture. Are you storing the data in a database? If so, make sure you're not vulnerable to SQL-Injection, etc. Good luck!


Are pwgen's default passwords "good enough" for online accounts and encryption? I found the pwgen Linux utility that seems to provide easily-rememberable and reasonably secure passwords. But the man page says :

  The  pwgen  program generates passwords which are designed to be
  easily memorized by humans, while being as secure  as  possible.
  Human-memorable  passwords  are  never  going  to be as secure as
  completely completely random passwords.  In particular, passwords
  generated by  pwgen without  the  -s option should not be used in
  places where the password could be attacked via an off-line
  brute-force attack.

Does using one of those pwgen passwords generated with default settings pose a real security risk, in the case of a brute-force attack ? Is it possible to work around the limitation by setting a bigger password size, like pwgen -n 13 ?

My use cases are mostly my password manager, local Linux user account, and Full Disk Encryption, all of which requiring brute-force-resistant passwords.

It's somewhat hard to quantify what is a 'real security risk'.  A password created with pwgen defaults (all lowercase letters, 8 in length) stored using a fast hash (MD5 or SHA1) could be offline brute-force cracked with a single modern GPU in anywhere from a few minutes (just trying lowercase) up to around 9 days against all characters (trying lowercase, uppercase, numbers, symbols).  If this same password is stored using a stronger hashing algorithm (scrypt, bcrypt, argon2, etc.) then it might be cracked using a brute-force against only lowercase letters but probably not by a full brute force against all characters (because it would take too long).

Your password manager and disk encryption should be using these slower hashing algorithms for key derivation.  With online accounts you often don't know what type of hashing they implemented so the safe bet is to assume fast hashes.

By my estimates, moving to a minimum password length of 11 characters for slow hashes and a minimum of 14 characters for fast hashes should help offset the weakness of using passwords constructed with only lowercase characters.  You can quickly increase strength by adding more length as your memory (or password policies) allow.

I will caution that these estimates assume attackers must use brute-force attacks (even if against a restricted selection of characters, like lowercase) to guess your password.  My understanding of pwgen is that, by default, it doesn't randomly create the passwords and instead attempts to structure them in a more memory friendly arrangement of consonants and vowels.  This probably causes a significant reduction in the number of possible passwords out of the total pool of lowercase random passwords.

So theoretically an attacker could identify only the possible passwords generated by pwgen and target those in their password cracking attempts to save time.  If this pool of pwgen passwords is 15% of the total lowercase possibilities (I have no idea what it actually is) then 11 characters would probably not be a sufficient minimum length.  You'd need to go with a 12 characters minimum, adding more characters to satisfy your particular paranoia and future-proofing preferences.


Check if the source ip belongs to that user i'm trying to understand more advancedly on how we can prevent an ip spoofing .
since its impossible to know the original mac adress of a spoofed retour how we can check for example if the packets we sent or we received are going/coming from the retour (192.168.0.1) ? .

for example is it safe to determine that the seconde call of an Arp request is fake ? because it makes no sense after the first arp request the retour have its table set up and ready to go why will it sent more arp requests every time ?

if not , most of time a the source IP does not belongs to the spoofer his self so we cannot ping , is it safe to determine that its a fake packet ?

and if we can ping the source ip its source hostname is up and running how we can find out that the packet being sent or received is fake  ?

I'm trying to understand more about spoofing i might have some missunderstanding of some concepts so excuse me for any confusing terms !

how we can check for example if the packets we sent or we received are going/coming from the router (192.168.0.1)

You could hard-code the (MAC-address, IP-adress) mapping of the router and throw away packets claiming to come from the router's IP that didn't match the mac-address.

Most likely, nothing else will work reliably. However, fixing the MAC-address of the router will likely cause maintenance problems.

  is it safe to determine that the second call of an ARP request is fake?

Not necessarily. ARP tables are repopulated periodically. Hardware might be exchanged, explaining MAC-address changes.

  so we cannot ping , is it safe to determine that its a fake packet ?

No. Just because you can't ping a host doesn't mean it doesn't exist, or isn't real. It's firewall - or any firewall along the route - might simply discard ping requests.

Also, ping works above the ethernet level, so if someone successfully steals an IP-address on your network segment by poisoning arp caches / switches, he won't have any trouble replying to your ping. Basically, ping is worthless as an authentication method.

  and if we can ping the source ip its source hostname is up and running how we can find out that the packet being sent or received is fake

Set up an authentication protocol. If the host successfully authenticates to you, you know it's the real thing. If it can't, it's a fake. However, this doesn't work on the IP level - you'd need to build the authentication into an application level protocol, or use a preexisting one, such as TLS.


How to view e-mails without internet connections? If I want to make a secure PC that has zero network connection, how can I view my e-mails on it? Are there any tricky solutions to still view my e-mails while I have no network connection? And all that in a secure way?

Thinking of that I have another PC with network connection and a flashdrive?

The original problem is that I want to protect the informations on the secure PC.

What you are speaking about is an airgap, a device or network with no network connections outside of its own loop.

If you had an email client within the airgap then you could view emails that have been transferred over to the airgapped system on removable media, but you could still be infected by any malware that is contained within them.

A well known example of this is the famous 'stuxnet' malware. Although the exact delivery mechanism was not email,  it was targeted malware that was suspected to have breached the airgap via removable media.

The airgap itself will mitigate against many types of malware, even if it is successfully delivered. For example, droppers, c2 bots and other malware that requires an Internet connection to function and/or spread will not be able to function correctly.


Will browsers trust an expired self sign certificate in the Trusted Root store I recently discovered that if Windows AD LDS services are bound to a self signed certificate, that processes will continue to trust the cert even if it's expired. My guess is this is because the cert is in the trusted root of the machine making the requests.

What I don't know is, if that same cert is used to bind to an IIS site, will a browser give users error messages and ask them to proceed anyway?

That depends on the browser, the TLS implementation and the settings that influence certificate validation.

Every TLS implementation should not (from a better-security point of view) trust expired certificates, but the default behavior differs and is configurable.


What ports are okay to be open on a macbook pro? When I do a network scan for open ports on my MacBook Pro, I can see the following open TCP ports below.  Are these 'standard' open port for a personal computer of this type?  Should I be concerned? Are there any ports I should close for security purposes?  If so, how would I do this?

Open TCP Port: 631 ipp
Open TCP Port: 3413 svnet
Open TCP Port:  17500
Open TCP Port:  17501
Open TCP Port:  17600
Open TCP Port:  17603
Open TCP Port:  18800
Open TCP Port:  21324

Open ports are specific to each network interface. If you performed the scan from the MacBook itself, then chances are that you are seeing open ports that are exposed to localhost only, and not to the local network. It may be that a port is reachable from the same computer, but not the local network.

To view which processes use which ports, you can use the following command:

sudo lsof -i -n -P

This will print all ports and connections. Those with LISTEN are ready to receive connections.

On my MacBook only TCP ports 8021 and 29754 are open. You seem to have more open ports, but whether that's good or bad isn't clear without more details.

MacOS has a built-in firewall to block incoming connections. You can find the settings under "Security & Privacy".


If two programs on the same machine communicate through TCP, can it be seen from the outside? Assume there are two programs running on the same computer at the same time. The computer is connected to a LAN. The two programs communicate via a TCP socket, and the socket is opened using the IP address of the computer on the network, for example 192.168.x.x

In this case, can someone having control over the router, but not over the computer, see anything? (either just the connection being prepared, or the data itself) Do any packets ever leave the computer? Would it make a difference if the client connected to 127.0.0.1 instead of 192.168.x.x ?

Either of those IP addresses should be fine to keep it internal to your machine. If you tried to connect through your public IP address (Which most likely would require port forwarding) could expose information at the router level, but not outside of the router. Your Network interface card knows that it does not need to send packets out when the destination is itself.


Understanding firewalls I would like to understand how firewalls work in details, and understand the attack surface.

TCP and UDP

I understand that TCP and UDP are easy to filter. Programs on a computer need to ask the OS to open a port and will listen to these ports. Firewalls can simply look at all incoming packets, check the port number, and decide to allow it or not, based on the sending IP.

Are there attacks on other protocols ? What do firewalls do to protect from attacks from other protocols ?

Say there is a malware on a machine. Is the only possible way for the malware to communicate to the outside world is to open a TCP/UDP port? If we prevent a program from opening a TCP/UDP port, are we guaranteed that the program cannot communicate with the outside world?

TCP and UDP are layer 4 (transport protocols), and ports are an addressing feature particular to them.  There are many other protocols, and they do not use ports.  While malware often uses TCP or UDP, mostly to "hide" among normal traffic, it can use other protocols, or even one that the malware writers created on their own.

As Rashad pointed out, advanced malware can "hijack" normal programs on your computer, using them to communicate on their established ports.

Firewalls have many different strategies for inspecting data, from simple IP filters to deep packet inspection and application analysis.


Can website detect if I’m using chrome remote desktop? I was wondering if the website can detect the remote operation of my PC while I’m visiting.

For example;
I visit one website and click here and there while using  my laptop for controlling my desktop using chrome remote desktop.
Can the website find out that I’m remote controlling?

No.

The chrome browser http request and the Chrome RDP session are two separate things.

The browser might send the browser user agent in the header but not the way you are connected to your device.


Why are passwords limited to 16 characters? What is the reason that most websites limit to 16 characters?

I would have thought the longer the password the more difficult it makes it for someone to crack it?

Is it something to do with hash collisions?

If you are to abide by CWE-521: Weak Password Requirements.  Then all passwords must have a min and max password length.

There are two reasons for limiting the password size.  For one,  hashing a large amount of data can cause significant resource consumption on behalf of the server and would be an easy target for Denial of Service.   Especially if the server is using key stretching such as PBKDF2.

The other concerns is hash length-extension attacks or the prefixing attack against MD5.  However If you are using a hash function that isn't broken,  such as bcrypt or sha-256 ,  then this shouldn't be a concern for passwords.

IMHO 16 bytes is far too small.  bcrypt has a built-in cap of 72 characters,  which is probably a reasonable size for a  heavy hash function.  Key Stretching used by these functions creates the possibility of an Algorithmic Complexity Attack or ACA.


Why are wireless adapters needed for wireless attacks? I got into penetration testing a couple of weeks ago and just started learning more about wireless attacks and how they are done, and they mention a lot the need of wireless adapters.

Would I still be able to do the attacks without an adapter? How is it needed?

Thank you for reading :)

Many of the native wireless cards used in commercial laptops are not capable of packet injection. While you won't need this to monitor network traffic passively, you will need that capability to perform any of the wireless attacks. Furthermore, some of the native cards have compatibility issues with Linux (i.e. driver support isn't great).

For this reason, many of the tutorials out there tend to stick with two well-known and reliable wireless network adapters:

Alpha AWUS036NH
TP Link N150

Note: these are not product recommendations, rather frequently used devices in many entry-level wireless pentesting tutorials. I point them out for reference not recommendation. (Though I own -and use- both regularly).


Is a fake base station needed for IMSI catching? If you read about cell phone tracking it looks an IMSI Catcher always uses a fake base station the get the phones IMSI. I don't understand why this is necessary.

Couldn't they just passively read the signal and copy the phones ID from it's communication?

From what I read the signal might be encrypted but can be broken in real time. So why the trouble of faking a complete base station.

IMSI Catchers are fake mobile network cells (BTS) and additional equipment for call routing that operates in a "evil twin attack" and MiTM manner. They are usually positioned in places nearby the victim, where their signal is stronger than the signal of the legitimate network service provider cell, so the victim phone choose the fake BTS than the legitimate one.
When the phone try to negotiate the encryption scheme with the specific for the GSM protocol handshake procedure, the IMSI Catcher identifies the victim by it's IMSI and downgrade the required cryptography from A5/1 or A5/2 to A5/0 or "not encrypted". It basically tells the victim phone "i can't support anything but A5/0". When the phone starts to communicate with the IMSI Catcher and traffic channel is allocated for that client, all communications can be sniffed on the traffic channel, because there is no encryption.
Next, with the permission of the network service provider to access their HLR, the communication is encrypted with the subscriber master key, and routed through the network. This way, we can have two-way communication without the victim knowledge about the surveillance actions.

This can't be done without physical BTS, since it needs to receive and transmit on the RF media.


Securing SMTP server and its logs Looking for general mail server security best practices here.

I did some research and it's really hard to find the information out there.

How do you safeguard a smtp server log? Are there any encryption tools out there? Our reason is if the server is compromised, at least the logs are not in plaint text format for attackers to see without obtaining our tool/keys.
It seems like most SMTP servers out there store recipient information in the log files. How can we ensure these informations are not stored or at a minimum are scrambled. Is that possible?

Thank you and I'm still researching on the subject.

====
Edit

The context here is we are a gov agency trying to use a third party mail server for sending out mass emails. We are concerned with "client" email addresses being revealed or be read by third parties. How do we safe guard the recipient info as well as the mail content?

If you want to verify that the information on the SMTP logs is correctly and has not been tampered probably you will need to implement extra functionality on your M
TA. On the past, I worked on a project and we got the same problem, basically we implement some functions with PKI and Hashing (SHA1) to prevent any one could modify a log file (malicious admin). Not sure if opensource MTAs have that functionality.


How does google know if I am logging in from a new machine(using web browser)? Every time i sign into my google account on a web browser on a new machine, it warns me of suspicious activity. How does google know its a new machine? I am trying to implement a similar thing for my website, where I should allow the user to login without any notification if I know he had logged in from that machine before, whereas on the other hand, I want to notify user if the user is logging in from a new machine.

@Joe M.'s comment provides a good link as to how Google accomplishes this.

For what you are looking to accomplish simply capturing the IP address of the visitor seems like it would be effective in determining new or returning users, though this isn't enough, as multiple unique users could navigate to your site from within the same internal network (to your server this would appear as originating from the same external IP) and would need to be handled individually. If this was your only logic then you could only ever have 1 unique visitor per IP, which is probably not what you are looking for.

To handle this you would need to assign a unique cookie to each unique visitor. This works for Google because it will associate your username with this cookie. Unless you have something with which to associate the cookie (username, id, etc.) then it won't be possible because the requests could be spoofed by replicating request headers from another machine using the same external IP.

I suppose you could associate a WebGL fingerprint, which would be unique to the specific machine, and associate that along with the external IP for the cookie value.


How concerned should we be about RFID skimming? I've heard/read several pentesting stories where the pentesters clone RFID badges. I've also seen some articles saying RFID skimming is a negligibly small problem. The RFID skimming I'm talking about is where someone walks up to you to skim your card or "fires" a "skimming beam" from a distance, and not where you actively (unintentionally) put your card on/in a skimmer like on ATM machines.

All the articles I've read that say we don't need anti-skimming wallets and such mainly say things like "It's not common", "You get too much junk", "It's impractical resource-wise".

How common is RFID skimming? How concerned should the average Joe be about it?

(If I have some money, especially if I have access to some confidential data, I would definitely get anti-skimming stuff, but that doesn't sound like most people)

The article you point to presents things more from one perspective than the other.

From the same article, I find the statement :"RFID crime isn’t a great payback for the effort and risk." at least arguable.

If you wonder if cards can be read at greater range than stated, the answer is definitely yes. It's all a matter of the quality and power of your hardware. Given the hardware is good enough you can certainly obtain a good read distance.

Considering a few meters is quite accomplishable, this part of the problem is practically solved. High range read is quite possible. It's a matter of basic communications, just like trying to read a radio signal. With a powerful enough receiver you can get signals from hundreds of kilometers away.

Of course the RFID system in the cards is a passive element, but still it can be read from quite a range by normal means, not considering directed energy methods (aka the ray-mode, like a label scanner uses). So yes, I can enjoy my coffee across the street and make everyone on the restaurant on the other side make some 'donations' (and this would only be a beginner method).

The general defense against this is most of the time the limit of the amount transferable. In my country, that amount is the equivalent of roughly 4 Euros or $5. It may not seem much if taken from a person or 2 but if taken from hundreds or thousands it may become profitable very fast.

You will indeed need a relatively complex back-end setup where your reader can actually provide you the transferred amounts, which is actually the risky part the article talks about. This is the reason most current CC-frauds do not rely on such actions - there are other simpler methods to hit high ends of money without resorting to this. Think of it as the equivalent to robbing a very large bank compared to robbing quite a lot of small local ones.

But this does not mean it won't happen.
It is technically very viable and it can be done in such a way to earn extreme amounts of money before anyone ever realizes there's something wrong. It just needs the proper setup (tech setup and key location).

As for the average people, they are not really concerned a lot due to the limitation of the transferable amount. Losing E4/$5 is not much of a damage. But gaining it from a few dozens of thousands of people that can enter daily on a large China-type mall-area can be a big earn. That is why it is increasingly likely that in the future we will see such a large scale skim.

So why not protect if possible ? A foil case for your card is cheaper (you can find them even under $1) than the amount you may lose in only one transactions and you can keep it for years.


What is "Waiting for eb2.3lift.com...."? I am using purevpn on Firefox, I have noticed that when I open the browser sometimes it hangs and on the bottom left hand corner it says "Waiting for eb2.3lift.com..."

I tried to google this eb2.3lift.com but don't seem to find any answers. Does anyone know is it malware /virus related?

P.S. I have AVG free version installed, I did a system scan & found nothing.

It's the API servers for the advertising network triplelift.com. Most likely, they are benign, but they are also useless for whatever you're trying to view. Most ad blocking extensions should block their cookies and advertisements automatically.


Can symmetric key cryptography provide identification? I understand that PKI uses digital certificates to link a public key to an entity, but is there anything similar for symmetric cryptography.

If, theoretically, PKI didn't exist, how do you know you are sending your ciphertext to the right person?

Is the security in the fact that even if you are sending the encrypted text to the wrong person, they won't be able to read it as they don't have the secret key? Would this not be dangerous as they can attack the ciphertext?

For example, Alice wants to send an encrypted message to Bob. Is there anyway (without PKI) Alice can know that her ciphertext is reaching Bob, and not Chris, who is pretending to be Bob? Does she have to rely on the fact that Chris wouldn't know the key so it would be considered safe?

There are no 'digital certs' to be used in symmetric encryption to tie a user to an address for example.

The whole point of all encryption is that it's safe for the attacker to get your ciphertext, because they don't have the key. This is true for public-key encryption as well; it's perfectly safe for you to broadcast your ciphertext to the world, and certificates aren't related to that in any way.

The reason you use certificates in public-key cryptography is to know that you're encrypting something with the right key, because the key is generally sent over an insecure channel. With symmetric crypto, the analogous concern is that the person you talked to when you exchanged keys was an imposter; however, symmetric key exchange requires a secure channel with whoever you'll communicate with later, and so you can work out identity issues when talking directly with them.

Once you've directly tied a key to them, you can use message authentication codes to make sure that a message came from them and not from an imposter. Unlike digital signatures, you can't prove anything to a third party; with a symmetric scheme you know everything the other person does, so you could forge a message that looks like their messages. That's not an issue when you're talking to them because you know you didn't forge a given message, but you can't take that and prove it to someone else.


Pirate Bay Search Appearing in Chrome While googling some errors today I noticed I had the option to use

the pirate bay search

Now I saw a similar question posted here How did piratebay.se search engine get in Chrome as an “other search engine”
But my problem is different.
It only appears when I search what I was searching in the above photo, it doesn't appear for anything else, or at least I haven't found another search combination where it has appeared.
eg

It only appears when I use the below search.

As well, there is no extension in my chrome browser which installs this, it's just there.

Now the obvious answer might be, oh you visited PirateBay at some stage and that's why it's there, But I can guarantee that this system has never once been on the site, the last thing I googled which included the word Pirate was "Pirate Jokes" which, unfortunately turns up some good results.

I have scanned my system for Malware and Viruses and there's nothing.
So -

The machine is free of Malware and Viruses
The machine has never visited The Pirate Bay before
There's no Chrome Extensions for "The Prate Bay Search"
It only appears for certain Syntaxes

Basically my questions are -

How could that have gotten there
Is there anything to worry about
If so, what would you recommend

Thanks in advance
Edit One:
If i try to search using it, it will re-direct me to the piratebay

We block the website so it will never go there, but it could potentially cause issues for a network where Torrent Sites are not blocked.
Edit Two:
So my new question is.
Can this be a vulnerability to a users machine?
If a company or user did not have sites like that blocked and a user searched it accidentally, could they be infected with malware, I'm thinking of a JavaScript exploit or something similar as 90% of users I imagine just click "Allow" or "Okay" on pop ups.

https://en.wikipedia.org/wiki/Blackhole_exploit_kit
https://heimdalsecurity.com/blog/javascript-malware-explained/
I've encountered JavaScript attack code - how do I search for information on the exploit's specifics?

This is a Chrome feature.
Chrome is suggesting some of the search engines you've used at some point based on keywords in your search query.*

Open chrome://settings/searchEngines to see that The Pirate Bay is there.

* You say that the device has never visited The Pirate Bay before. Did not, or just deleted it from history? I'm not sure whether deleting the history will delete all the other search engines too.


Performance comparison between ed25519 vs AES I found that AES has dedicated hardware on most machines. The question is can we use ed25519 to replace AES? Instead of using RSA to encrypt the AES key and then encrypt the data with AES, can we just use ed25519 and stop using AES? Are there any performance comparisons between the two? I went through this and couldn't find much.

You're comparing a signature scheme (ed25519) for integrity / authenticity with an encryption scheme (hybrid RSA / AES) giving you confidentiality. As such, the comparison makes very little sense.
If you want to speed up encryption then you could replace RSA encryption of the key with ECIES, for instance using X25519 as key agreement scheme for Curve25519. You would still need the AES encryption as ECIES is really just Diffie-Hellman key agreement: the actual encryption still needs to be performed using a symmetric cipher. You can choose any symmetric cipher for that, but on most modern computers AES is pretty fast. There are however stream ciphers such as ChaCha20 that are extremely fast where hardware AES acceleration is not available.
Obviously then, the above scheme will only remove the slowdown of the RSA (un)wrapping of the AES key. No asymmetric scheme is likely to be faster than AES.
If you go for the curve with stream cipher approach you might as well use one of the NaCL compatible libraries. Another advantage of doing that is that you will get a lot of low level security and performance for free (assuming you manage to choose a secure & fast implementation).


Vulnerabilities by adding an untrustworthy package repository Often, users will install additional package repositories to their Linux distributions to be able to follow "bleeding-edge" versions of software that hasn't been/will never be backported to their distribution version.

Say that packageA provided by repoA depends on libssl. Originally, no problems found; the only possible vulnerabilities would have to be supplied directly by packageA.

However, if the owner of the repository packages libssl and includes it in their own repository (I've seen similar things in the wild), my system libssl will be replaced by their compiled version of OpenSSL.

With this said, how difficult is it to do this? Do package managers (e.g. apt, yum) provide any protection against this? For all the user knows, a malicious repository could package a rootkit in a package called libssl which in fact doesn't provide any SSL support whatsoever. If I understand correctly, if this were to happen, the user would receive no indication that this was happening, and their machine would be compromised with a simple apt-get upgrade.

As a general rule most package managers will ask you if you want to install dependencies, as well as asking if you want install different (versions of) packages.

Whenever I download a package from somewhere that's not debian's repos (I use Crunchbang linux) then I'll install the needed dependencies myself and only use the third party repository for the one specific package I want.

Afterwards, I'll comment out the line in my sources file that has the third party repository so when I do run 'apt-get update' I won't get anything from that repository. (The only downside is it requires an additional step to update the package from that repository.)

Usually when you update or upgrade you'll be shown all the packages that need updating. If you pay attention, you'll notice anything funky going on.

Edit: Just found an example when trying to upgrade Mono

Need to get 55.8 MB of archives.
After this operation, 33.8 MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
**WARNING: The following packages cannot be authenticated!**
  mono-complete mono-runtime-sgen mono-devel mono-dmcs...

It's from a non-Debian source, thus the warning and forcing me to select Y again.


Gmail Voicemail Encryption I want to listen to my voicemails in a secure but convenient fashion. I plan do this by having my PBX encrypt the voicemail using openssl aes 256 cbc with salt and a single static password. The voicemail would be emailed to my Gmail address where I am creating an chrome app to decrypt it using the established static password and play it.

What are the security implications of establishing such a system or is there a better recommended encryption setup? Also, as a side note, would this setup be considered HIPAA compliant?

Good news! It looks like Gmail is HIPPA-compliant IF you are using a Google Apps domain and have requested a BAA from Google. A BAA is required for you to use external companies for such services for HIPPA compliance. Normal Gmail addresses are not HIPPA compliant AFAIK.

Your setup sounds OK - I would rather see some kind of changing password, which would at least offer protection against someone finding one password and having all voicemails.

If I were you, I'd rather create a HTTPS website to check your voicemail that can only be accessed via a VPN. While HTTPS is secure, if you put the information on a public web server, you open it up to other methods of attacks. If you have it available on your network only, then VPN into your network, someone will have to perform several attacks to get to the data you are trying to protect.

-- I'm sure you know how much the fines are for HIPPA failures. Make sure that you only use a Google Apps Gmail address with a BAA. It's worth the $50 per year for one account if you don't have it.


A filesystem with chunks hidden all over the internet? I am wondering if there are any implementations of a filesystem (as in FUSE) that would allow me to host a file in chunks steganographically distributed all over the internet.

The way I imagine it, the user needs a master URL with the first block containing an encrypted list of the URLs for remaining chunks of data, hidden steganographically in different websites. When the user wants to modify a chunk, the filesystem would create a new chunk and - at the end of the work - generate a new master URL containing the final list of URLs listing the chunks of a new version of the file.

Would such a system work if the master URL contained URLs of multiple copies of the blocks saved on different websites in different formats (i.e. audio, video, image, forum comments with the text hidden with whitespace)?

The need for such a distributed file store is largely filled by Freenet.   Freenet is a distributed hash table where by various chunks of a file is obtained anonymously from various nodes in the network.

The addition of stenography upon Freenet would add a level of secrecy in that only people who know where to look can find the information.


How does Tor protect against an attacker just running thousands of nodes? Does Tor have any protection against an adversary simply running a very large number of nodes?

Someone with the necessary resources could just run thousands of relay nodes (including exit nodes). If they were an organization like the NSA, they could also make the major hosting companies running nodes turn over the private keys, or install backdoors, without the "owner" of the node noticing.

I know tor employs entry guards as a protection - a client chooses a set of entry guards at random, and only ever connects to those as entry nodes. If the entry guards are uncompromised, the user is safe. This gives the user at least the chance of not being profiled; without entry guards the user would eventually be caught.

However, what if the adversary is not interested in busting all users that access a certain site, or targeting a specific user. if they just want to identify some random portion of users that access that site, couldn't they do this by running a few thousand nodes and waiting?

I can imagine they could even target specific users, and force them to use only compromised nodes. Compromise one guard node of the user (wiretap his line, observe what server he connects to and send them a court order or some thugs, or just be lucky and control the right nodes by chance). Then run thousands of modified clients. Once the targeted user goes online, flood the network momentarily. In cooperation with your compromised nodes, keep the compromised paths free, so that the client will eventually build a circuit only on your nodes.  Voila, you can eavesdrop on the user.

Are there any protections against this in Tor? Can you give an estimation on how many nodes the attacker would have to run? Are there any non-technical countermeasures, e.g. would someone intervene if 3000 new suspicious nodes would pop up on AWS?

(Note this is different from other questions on this site. For example my previous question asks about the case where the attacker can completely control your line; he fakes the whole network. Tor guards against this by using a list of known good nodes, and using signatures.)

Tor provides privacy only under the assumption that at least one node in the randomly selected chain is not attacker-controlled (since we are talking about traffic analysis, simply eavesdropping on traffic entering and exiting this node, without trying to decrypt it, counts as "control"). This is probabilistic. If the attacker controls, say, 50% of all nodes, and your browser uses a chain of length 5, then the attacker wins with probability 0.55 = 1/32.

To mitigate such attacks, you can configure your client to choose chains non-uniformly, but instead to enforce a "global spread" so that the chain will go through nodes in several countries who don't like each other.


DNS spoofing over https If a device sends a request to https://example.com and someone spoofs the DNS response to redirect the request to some malicious server. Would the attacker be able to modify the packets during the TLS handshake to make the original request domain name match and therefore establish the connection?

TL;DR: No.
The TLS connection needs to validate the server certificate, and the attacker will not have a valid example.com certificate. He can either create a self-signed certificate, or a certificate signed by a CA (Certificate Authority) that he owns. And that attacker will not own a valid CA that is trusted by browsers unless he is a government, and even if he is, his CA will be blacklisted very fast.
On both cases, the client browser will show the "Invalid Certificate" warning, and the client will have to acknowledge that and tell the browser to load the site anyway.
That's why TLS was created: to defeat MitM attacks like that. With the certificates and list of trusted CAs, every client can be sure that he is talking to the server he thinks he is talking to, and nobody but he and the server can know what is being transmitted.
There are a couple issues with TLS (and SSL before it) that can allow an attacker to know what is being transmitted or change something, but those attacks are quickly patched.


Protect computer from usb device I need to plug a cctv style camera via usb on my computer in order to read what it recorded.

In general, how can I protect the computer I plug a usb device into, if I am worried the USB device might contain malicious code (e.g. malicious firmware from the manufacturer itself)?

Note that my question is different from this other one which refers only to usb drives, whereas mine relates to USB devices (camera). Also the context is different (home versus hospital).

If you are really worried that there may be some malware on a removable device than your best bet is probably to run a live linux disk to check the device.  This will give you the ability to access / scan any devices without putting your local hard disk at risk.


How do I get SSH to prompt me with the RSA key instead of the ECDSA key? I am trying to SSH into my fresh Ubuntu 12.04 server.  At the client I have deleted known_hosts.  SSH to the host for the first time has it offering me an ECDSA key to verify.  The problem is I know how to get the RSA key and verify it but I don't know how to get the ECDSA key.

How can I force SSH to prompt with the RSA key and store it if I approve?

I have tried:

ssh -o RSAAuthentication=yes user@server

Unfortunately this gives me an ECDSA key and the Are you sure you want to continue connecting (yes/no)? message.

You can also tell the server what algorithm to use from the client (for example if you already have the rsa fingerprint written down and are physically far from the server)

  ssh -oHostKeyAlgorithms='ssh-rsa' host


(Why) does an encrypted MS Office 2010 Spreadsheet (need to) have the password hash "written down"? To my naive mind, it seems like the encryption of a document with AES should go like this:

HumanPassword ---|hash|--> key ---|AES|--> Ciphertext

                       plaintext|--^

And the decryption like this:

HumanPassword ---|hash|--> key ---|AES|--> Plaintext

                      ciphertext|--^

And as such it seems that the encrypted package (the excel file) should not need to contain the hash of the human password, and furthermore, that it would be insecure for it to do so.

One of my co-workers says that "if the file didn't contain the hash, what would it compare the password to?"

It seems to me like it needn't do any comparison. It should decrypt with whatever key it gets from the hash, and if it worked, the result won't be nonsense. If it didn't work, excel should see nonsense and say "Wrong password, nincompoop." But it shouldn't have the hash in the file. It shouldn't need to compare anything.

However, it seems that it does have the hash in the file.

When my coworker and I picked this file apart, we found that there was indeed a hash value in there, and we are now running dictionary and brute-force attacks against it.

So I suppose my question is this:

Why does an encrypted MS Office 2010 document need to store the hash of the password?

And, if secondary questions are appropriate on SE,

If it doesn't absolutely need to, why did Microsoft choose for it to?
Isn't that less secure if the hash algorithm isn't very good?

This is a case where security has been scarified for usability.

The hash acts as a checksum. If they had nothing to compare it to they would not be able to determine if the file was in fact decrypted with the correct password. Without this comparison it would blindly try to load in the file. A wrong password would mean it would load in corrupted. And the user/application would not know if this corruption was due to a wrong password or some other issue.

Additionally the hash is not a direct hash of the key. In Office 2007 it hashes the password 50,000 times and in Office 2010 it hashes it 100,000 times. Both using SHA-1. This is to fight off tools that brute forced hashes for earlier versions. Office 2013 uses the same strategy but uses SHA-512 by default. As a result the hash is safe for redistribution. You can learn more about the password protection here.

With this said it is still possible to brute force. Ultimately the strength of the key is up to the end user.


Is there any way to estimate the safety of arbitrary binaries, which are usually released with unofficial patches? Frequent scenario:

An old game is released on GOG / Steam.
It proves to be incompatible with new Windows systems. (Crashes, game breaking bugs, fps of 0.5 and the likes)
An unofficial patch is released by the fanbase, either for this particular game or for a range of games that use <obsolete technology X>. This unofficial patch is released in the form of a .exe file that is supposed to repleace the game's main executable, a .dll to be placed in the game's folder, or instructions how to manually patch the game's executable. Sometimes the patch is even released on github with source code.

My question is, how to estimate the safety of those binaries?

I suppose that it is hardly possible to include malware by arbitrarily changing a few bytes in the executable; so this should be safe;
Github binaries with source code provided should hopefully be safe, though I may be naive here, especially since out of box builds may differ from the source code
Arbitrary executables provided on fansites dedicated to the game are only as safe as the site is reputable... but that's an odd way to say that if the admin isn't known to have included malware within past 10 yrs they're unlikely to include malware now?

Bottom line:
* Is the only reasonable approach to never run any binaries from the interet outside of the virtual machine unless they've been tried by half of the world already (I mean cases like League of Legends or even Battle for Wesnoth), at least if I don't want to see that my files were encrypted and I have to pay XXX BTC to have them decrypted;
* Or are there any other ways to estimate the safety of an arbitrary binary?

I suppose that it is hardly possible to include malware by arbitrarily changing a few bytes in the executable; so this should be safe;

Viruses can easily be as small as about 50 bytes of code, so changing a few bytes isn't an indicator. Granted, most AV can detect viruses this small, so the risk is minimal, but be aware that it doesn't take much to turn a normal executable into a bomb.

  Github binaries with source code provided should hopefully be safe, though I may be naive here, especially since out of box builds may differ from the source code.

True, your best bet is to build your own binary, but Open Source Software tends to be safer only because there are so many people looking at it. If something was amiss, it'd probably be reported before it had a chance to do much harm (but, note that things like Heartbleed still get out in the wild despite such assurances, so it's not foolproof).

  Arbitrary executables provided on fansites dedicated to the game are only as safe as the site is reputable... but that's an odd way to say that if the admin isn't known to have included malware within past 10 yrs they're unlikely to include malware now?

On the internet, reputation tends to be important. That's why sites like Stack Overflow actually work. I would say that over 99% of "fan sites" are probably likely to be legitimate, because almost nobody wants to be the one that tarnishes the image of their beloved franchise. However, it's no guarantee. People that are out to do harm will most likely fake their 10 year reputation in order to seem legit, because ten years just to plant a virus isn't practical.

Overall, the only way to stay 100% safe is to never run any code from anyone ever. There's always a risk. You can reduce the risk by using legitimate sites, but even those can be hacked. Always use an up-to-date antivirus, always check signatures, and always have backups. And always backup your data. There, said it twice. As long as you have everything backed up, you should be good to go. Real fans won't harm your computer, but be aware of posers that will. Almost all "pirates" prefer their reputation over doing damage, it's the scammers and crackers you should be worried about.


With a 'man in the middle' attack, can the attacker find out Client/Server session keys with a compromised AS/TGS secret key? Assuming that an AS/TGS secret key has been compromised by a 'man in the middle' attack who in turn can monitor the network traffic, is an attacker able to find out the Client/Server session keys between clients and services and can they find out which clients are trying to access which services through service ID's?

If a man in the middle was able to get your AS/TGS secret key, then you are doing it wrong.  The entire point of the secret key is that only the TGS knows it and it shouldn't be discoverable.  Preventing a man in the middle attack is the main point of the TGS having a secret key.  If the secret is no longer secret, a man in the middle is possible because the attacker can pretend to be the TGS and you are completely screwed.


What is truly unbreakable these days? Just very curious, count my knowledge in cryptography, algorithms, and security in general as non-existent. Now I am aware that this might be a VERY broad question, but here it goes. What is the most secure and virtually unbreakable cryptography to secure data in today's standards (and of course tomorrow's). Tips and tricks to keep the hackers and THOSEWHOWESHALLNOTNAME at bay?

Everything is unbreakable until it isn't. Knowing whether a system will ever be broken in the future requires more knowledge than simply can't be had today.

But to the best of our knowledge, all evidence suggests that today's commercial encryption (RSA, ECC, AES, .etc) is, in fact, unbreakable. That includes digital signatures, secure web traffic, consumer tools like truecrypt and 7-zip, and many of the things you use every day. As far as we know, they are impossible for anyone, from your neighbor to your NSA, to break....

Unless you count brute-force password guessing, side-channel attacks, and other forms of circumvention:

And that's the point -- there's always a weak point somewhere. Security can't be perfect. But the weak point isn't the cryptography. Instead it's the fact that your password is your girlfriend's dog's name spelled backwards. Or the fact that you stored a second copy of the document on Dropbox. Or the fact that a spy camera was recently installed in your ceiling.

Modern encryption is either completely unbreakable, or unbreakable enough. There really is no practical distinction between the two concepts, nor would you ever really be able to tell them apart.


Two solutions for CSRF on OWASP for ASP.NET WebForms I am confused about differences between those two solutions from OWASP ASP.NET Web Froms Guidance

Solution one:

  While viewstate isn't always appropriate for web development, using it
  can provide CSRF mitigation. To make the ViewState protect against
  CSRF attacks you need to set the ViewStateUserKey:

protected override OnInit(EventArgs e) {
    base.OnInit(e);
    ViewStateUserKey = Session.SessionID;
}

Solution two:

  If you don't use Viewstate, then look to the default master page of
  the ASP.NET Web Forms default template for a manual anti-CSRF token
  using a double-submit cookie.

private const string AntiXsrfTokenKey = "__AntiXsrfToken";
private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";
private string _antiXsrfTokenValue;
protected void Page_Init(object sender, EventArgs e)
{
    // The code below helps to protect against XSRF attacks
    var requestCookie = Request.Cookies[AntiXsrfTokenKey];
    Guid requestCookieGuidValue;
    if (requestCookie != null && Guid.TryParse(requestCookie.Value, out requestCookieGuidValue))
    {
       // Use the Anti-XSRF token from the cookie
       _antiXsrfTokenValue = requestCookie.Value;
       Page.ViewStateUserKey = _antiXsrfTokenValue;
    }
    else
    {
       // Generate a new Anti-XSRF token and save to the cookie
       _antiXsrfTokenValue = Guid.NewGuid().ToString("N");
       Page.ViewStateUserKey = _antiXsrfTokenValue;
       var responseCookie = new HttpCookie(AntiXsrfTokenKey)
       {
          HttpOnly = true,
          Value = _antiXsrfTokenValue
       };
       if (FormsAuthentication.RequireSSL && Request.IsSecureConnection)
       {
          responseCookie.Secure = true;
       }
       Response.Cookies.Set(responseCookie);
    }
    Page.PreLoad += master_Page_PreLoad;
}

protected void master_Page_PreLoad(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
       // Set Anti-XSRF token
       ViewState[AntiXsrfTokenKey] = Page.ViewStateUserKey;
       ViewState[AntiXsrfUserNameKey] = Context.User.Identity.Name ?? String.Empty;
    }
    else
    {
       // Validate the Anti-XSRF token
       if ((string)ViewState[AntiXsrfTokenKey] != _antiXsrfTokenValue ||
          (string)ViewState[AntiXsrfUserNameKey] != (Context.User.Identity.Name ?? String.Empty))
       {
          throw new InvalidOperationException("Validation of Anti-XSRF token failed.");
       }
    }
}

What I didn't get is this comment about the first approach: "To make the ViewState protect against CSRF attacks you need to set the ViewStateUserKey." Looking at the code for the second solution, it clearly using ViewSate in the code, I assume the author means that "using ViewState to persist control state". So if EnableViewState is set to false in for the page or master page, the first approach will not work at all?

Update: A better comment about the second approach in OWASP Anti CSRF Tokens ASP.NET

  Since Visual Studio 2012, the anti-CSRF mechanism has been improved.

  The new strategy still uses the ViewState as the main entity for CSRF
  protection but also makes use of tokens (which you can generate as
  GUIDs) so that you can set the ViewStateUserKey to the token rather
  than the Session ID, and then validate it against the cookie.

The tricky part for me, at least, is to construct a successful/working example CSRF attack, then it is trivial to implement both approaches and see them in working and actually mitigate the CSRF attack.

The first approach, using ViewStateUserKey only, seems not been affected by turn off enableViewState, either in page level or in web app level. As hidden ViewState is still in the rendered HTML, and the process of encoding ViewState is still in place so that you can not turn off ViewStateUserKey by simply turn off ViewState.

On the other hand, as the second approach is using ViewState for the storage of AntiXsrfTokenKey, it will stop working if the ViewState is disabled. So the comments from that OWASP page are wrong, or at least, misleading, the other comment from OWASP other page is much better and clearer.


How will Gmail be able to detect SPAM and display ads when emails are encrypted end-to-end? Context

Google is making end-to-end encryption easier to use.

SPAM

How will they be able to perform SPAM detection when the email is transmitted and stored encryptedly?

I suppose that if the SPAM email sent to everybody has the identical body, then the encrpyted text will be identical, so it can easily be identified as SPAM once people start flagging it as such.

But even if only one bit is different, the whole encrypted text will be different. What ways are there to detect SPAM emails then?

Advertisement

How will displaying ads work, when the email is only decrypted in the user's browser, i.e. locally?

Use client-side code to parse the email once it's decrypted, send keywords to the server and fetch ads to display?

The answer to the first part of your question is the current Gmail spam filters would not be as effective, they could read the header information and block certain sender addresses but they could not read the actual message. Your assumption that all the encrypted spam message bodies would be identical is incorrect, every individuals public key would produce a different message body even though the original message content is identical.

As far as advertisement is concerned the ads served to you would not be as individually tailored to you, there is already an option to opt out of user specific ads. If the client where configured to send back keywords to Google to serve up individual tailored ads it would be a major privacy violation, hopefully the extensions/plugins they promote are open-source and open to scrutiny.


Does any VPN protocol authenticate the server? When you connect to a server using SSL/TLS the client authenticates the server using the certificate that the server provides. If certificates mismatch an error page is shown instead. So you know you are connecting to the correct server.

SSH also provides a similar mechanism "server fingerprinting" to make sure you are connecting to the same server after the first connection. Microsoft's RDP does that too.

But I don't know if VPN protocols (L2TP, PPTP, OVPN) support this. Which are those? If we use those protocols can we be sure that the first connection's server fingerprint will be remembered and we will be warned the next time? (at least on major OS's?)

I'm asking because foreign WiFi spots can easily redirect VPN connection attempts and provide their own server which actually destroys the whole point of VPN.

OpenVPN is in fact based on OpenSSL, and uses both client and server certificates to authenticate both sides.

PPTP, SSTP and L2TP can be deployed in various modes, including modes with certificate-based authentication. Note that these protocols doesn't provide underlying encryption, which is provided by optional, associated IPSec layer.

And IPSec can use either static, symmetric keys or IKE protocol stack to exchange and manage such keys. In both modes both server and client and authenticated.

Of course nothing will protect you from sniffing and/or redirecting your traffic in raw, encrypted form. But such form will be useless most times for anyone (except for forensincs purposes, but that's outside of the question).


When you use a cellular connection how is your internet connection encrypted When you use a cellular connection how is your internet connection encrypted?

Usually there is some sort of key like with WIFI the wifi password is the key used to encrypt data?

How does encryption work on a cellular network when connecting the the internet?

Does it use the AT&T password on your account?

For example if I log into a bank on my phone is that password sent encrypted all the way?

While the cellular connection does implement a level of protection on certain segments, that's really not pertinent. Even if the cellular network is completely in the clear, it's the HTTPS encrypted connection to your bank that protects your password all the way to the bank.

No, none of the other passwords matter.


Security precautions for shared iPads in a customer facing corporate environment Most tablets, and iPads in particular, are typically single user devices.

Scenario: A service business that interacts directly with customers in person and wants to use iPads while interacting with customers during the sale and for customer service. There may be native apps and web apps. Because not all sales/services agents will need an individual iPad, there is plan to share a number of iPads in a given location between numerous employees.

What precautions need to be taken in order to ensure information confidentiality, as employees may need to put data for their individual clients on the iPad, which should not be accessible to other employees. What other risks should one consider in this scenario, such as stored credential exposure or tying auditable events to a particular user?

Are there any native configuration settings or setups that can be used to secure the use of shared iPads? Are there any tools or techniques which others are using to manage this scenario? Something like Deep Freeze or a quick base-image reset may work if some type of per-user profile could be loaded?

We've recently been testing Good for Enterprise which has turned out to be great. Users can install it on any device IOS or Android (assuming it is compliant to your standards(ie not jailbroken for example)) then set up quickly and easily. All your personal data (email, contacts, documents etc) are synced and stored within the encrypted application. If you unenroll one user and re-enroll another then there won't be any remnant data on the device inside the app so it could easily be shared between users. Set up takes a minute or two and is quite painless. You can also push out applications to the users via the 'Good' application.

Other things that might be  of interest to you, Defense Signals Directorate IOS Hardening Guide
and a list of mobile management software.


Generate a PGP key with  more than 4096 bits? I would like to know if generating a PGP key with a number of bits higher than 4096 is possible and if so how?

Yes, though some source code twiddling may be needed, you can generate 8,192 bit keys. In fact, I've seen some instances of 16,384 bit keys generated courtesy of the "Cyber Knights Templar (CKT)" builds of PGP "back in the day."

This blog post gives you an idea of where to look in the GnuPG source to bump that limit.

There are no different legal encumbrances to key sizes larger than 4,096 than there are to 4,096 bit keys. Just know that since there aren't a lot of keys larger than 4,096 bits floating around, the software of others might not work with them. I'm a bit curious to look into that now.


Does Adobe Acrobat Reader DC upload opened PDF files? I'm wondering if Adobe Reader DC uploads all the PDF files it opens to the Adobe Cloud, even if you have not signed up for the cloud.  I am not a fan of Adobe and generally do not install Adobe products on my computers if I can avoid it.  Unfortunately I have to fill out a PDF form that only really works properly with Adobe Reader DC.

I've installed Adobe Reader DC and noticed with Wireshark that it is doing "something", despite the fact that I've not logged into their cloud service and made an effort to disable their auto-update auto-reporting auto-spying on me services.

Does Adobe Reader DC upload PDF files to their cloud when it it used out of the box, with no Adobe account?

Update

I didn't save the original Wireshark capture.  At the moment I'm not seeing much more than an ACK.  The output from lsof -iTCP looks like this:

COMMAND   PID    USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
RdrCEF  10150       x   43u  IPv4 0xaaaaaaaaaaaaaaaa      0t0  TCP 10.x.x.x:51620->ec2-34-227-124-173.compute-1.amazonaws.com:https (ESTABLISHED)
RdrCEF  10150       x   49u  IPv4 0xaaaaaaaaaaaaaaaa      0t0  TCP 10.x.x.x:51621->ec2-52-86-116-151.compute-1.amazonaws.com:https (ESTABLISHED)
RdrCEF  10150       x   50u  IPv4 0xaaaaaaaaaaaaaaaa      0t0  TCP 10.x.x.x:51622->ec2-52-86-116-151.compute-1.amazonaws.com:https (ESTABLISHED)
RdrCEF  10150       x   52u  IPv4 0xaaaaaaaaaaaaaaaa      0t0  TCP 10.x.x.x:51624->ec2-52-20-243-157.compute-1.amazonaws.com:https (ESTABLISHED)

If I click one of the services like "Convert", it opens a browser window showing me pricing information and a lot of encrypted data is sent back and forth.

I don't think it likely that Adobe is automatically uploading your PDF to their servers.  Collecting all PDFs from all users would be a large about of data, without any visible financial gain.  If you want to confirm that your documents are not getting uploaded I can suggest the following ways:

Create a local proxy server which uses an SSL certificate which you
control.  You should then be able to decrypt any traffic sent to
Adobe's servers.
If the reader implements certificate pinning, or
setting up a proxy is not possible, try opening another document,
preferably much larger than the original. Make sure the document
does not compress well. If the size of the encrypted data in your
Wireshark trace increases significantly, then it's possible that
your data is being uploaded.

If you don't want to worry about your data getting sent off to Adobe, consider either blocking it at the firewall level, or adding a hosts entry to sinkhole any of the domains specific to the traffic you want to block.


Are Cisco switches vulnerable to VLAN hopping? Are Cisco switches vulnerable to VLAN hopping?  We use Layer 2+ and Layer 3 switches in a hardened environment.  They are IE-3000 and IE-4000 series switches.

We want to perform a vulnerability scan at many levels, but we are concerned mainly about VLAN hopping since each VLAN should be seriously separated from each other.

TLDR;
Prevention:

Don't allow ports to negotiate trunk with any device that asks for it.
Don't put hosts in the native VLAN

I have done demonstrations in the past on Vlan Hopping and this usually comes down to configuration of the devices and the series of switches.

For example, in Cisco's Catalyst family of switches, DTP is set to 'desirable' by default, meaning that it is willing to trunk and all you have to do is tell that port that you want to trunk and it will create that trunk link and negotiate the encapsulation protocol (Usually 802.1Q). I demonstrated this using a tool called Yersinia.

Some families of Cisco devices don't even use DTP at all and use a different process and/or protocol for negotiation of a trunk link.

Another variable that has to come together for this attack to happen is the use of the Native VLAN.

An easy way to prevent such attack is to not place any hosts in the Native VLAN and/or set DTP mode to nonegotiate.

Overall, you'll have to see if the IE series uses DTP. If it doesn't but uses something similar then make sure your ports will not auto trunk with any device that asks for it. This would essentially prevent a rogue device from trunking and sending double encapsulated packets which also needs to make use of the Native VLAN.

To say your devices are vulnerable or not is hard without seeing the configuration but the above methods with help prevent the attack from succeeding.


While copying data from any email client to a USB device what residue information is left on the PC? I often end up using netcafe's for browsing web (Windows 7).

I recently wanted to download some secure data from my gmail account on to the USB pen drive.

So, I went ahead and opened the attachment and copied it directly to the pen drive.

But now I am worried if any kind of backup or residue files may have been left on the PC I used.

I want to know what kind of information might have been left on the PC during the process.
And is it possible to use this data to generate back the original file content from it?

The files copied comprised of .jpeg, .doc and .txt files.

Assuming that the PC was "clean" (and that's a big "if"), then it partly depends on the Web browser. The file, while being downloaded, first goes through the buffers (in kernel RAM) associated with the socket. Then it is copied into the address space of the process which does the download, i.e. the Web browser. That browser then decides to have it written into some sort of file; this again entails sending the data into kernel space. The data goes to the file cache (the nominally unused physical RAM; the kernel uses it as temporary storage for data read from and written to disk), and finally to the disk which has been designated as target.

Internet Explorer, apparently (I just tried with IE 8.0), when downloading a file, will ask for the destination, and, crucially, will not download anything until the destination is chosen. When the data is obtained, it is sent directly to that disk. Firefox, on the other hand, begins the download as soon as you click on the link, and proceeds while you choose the destination. The file is temporarily written in an area meant for temporary files (on Linux it would be /tmp, but on Windows there is a per-user folder for that, see this page).

Therefore, with some Web browsers, a copy of your file made it at least temporarily to the hard disk of the computer. That file should have been deleted, but deletion does not imply wiping the data out from the physical medium; it just marks the used sectors as "reusable".

Another way your data may have leaked is through virtual memory. When the OS is short on physical RAM, it moves some of the data which is in RAM, into some swap area on the disk. It is hard to control which part of the RAM is used for that; the OS kernel will try to do that only with least recently used RAM, but this is heuristic. Since, with all browsers, the downloaded file makes it to the browser RAM space at some point, parts of the file data may have been copied into the swap files, thus to the physical medium.

To sum up, it is entirely possible that parts of your files still lurk on the hard disk of the machine you used. Some Web browsers make it more probable than others (note that while the Firefox behaviour implies more leaks, it also improves user experience, so this is not a case of obvious stupidity on the part of the Firefox developers).

The PC was not clean anyway. Or at least you should not assume it was clean. Machines which are left to usage to use by anybody, including ability to plug USB devices, might be riddled with malware. Such malware could be a key logger, and that key logger now has your... Gmail password ! At which point your files are not safe at all.

To make it simple: by accepting to use a netcafe machine for confidential data, you are already betting that you will get lucky, and the machine is "safe to use". Betting that whatever traces of your data remain on the machine will not be harvested by evil people, is not a significantly riskier bet. By using the machine in the first place, you pushed your luck quite far; pushing it a little bit further should not be that much an additional concern.


Why do browsers clear HTML forms when the user click the back button over an HTTPS connection? There is already couple of questions regarding this behavior

Losing form data when clicking the back button on browser
Why are HTML forms sometimes cleared when clicking on the browser back button

None of them explains why developers of browser X design the browser's behavior to reset HTML forms upon hitting the back button for pages viewed over HTTPS connection. Anything related to security here? or it's just because using HTTPS suggests that data is very sensitive?

Some times, form data may be dynamic. Example, only when you select a country, the drop-down to select a state will be enabled. Now to actually know what values need to be filled in the "state" menu, the information about the "country" you just selected will be sent to the server. server will then send to the client, a list of all states that come under the country and will populate the drop-down menu.

Now, all these exchange of information between the client(web-browser) and server are done via encrypted channel using SSL. When You click on the "back" button, the current SSL session becomes invalidated. And all data exchanged over that session must no longer be valid. Even if you want to have the same values again when you visit the page next time, those values need to be communicated via a channel secured using a different session key.(i.e, a new SSL handshake will be initiated, resulting in new pre-master, master and session keys and the HTML form data will be encrypted with new keys.)

So, to prevent the data of old SSL session to be used in the current SSL session, the form  data will be cleared.

Note that sometimes, cookies and session tickets will be used to retain the form data/session keys. But servers generally dont support session tickets, rather they encourage having a separate session.


Spoofing LAN IP Address Traffic To give as much detail as possible, I am doing a Pentest for a client that has quite a few "terminal systems" meaning that they are simply a box with a connection back to the main server. These systems are at a different location than the main server, so if connection is interrupted than critical business functions may be stopped, and my contract is not such that I can fix it. (My contract simply waives all liability allowed under law from me). All locations are on the same VLAN as each other with only 1 line leaving through the main office.

Now with this topology, some of these systems have ssh servers installed onto them so the main office can connect to this remote office. They are fairly well locked down but from some other non critical systems I was able to recover some passwords and usernames including a previous sys admin that retired a few months ago. Every time I go to connect to the ssh server I receive a connection refused. I have determined that the sole connection to it is from a specific IP Address.

Is it possible to spoof my IP Address and mac address to trick this ssh server into at least letting me try to log in? However if I do this would I kick off the current computer and possibly disrupt traffic from it AND from the terminal (with ssh server) to the main server?

The only article on here that I found was Spoof another IP address in the same network,will the spoofing source get the response? and it didn't provide the specific answer I needed. I am more worried able keeping the services up rather than proving an attacker could log in. I could simple provide a redacted version of the user/password list and the method of IP spoofing (assuming this could work).

When you spoof ones IP the answer will not reach you at least not for a long time. As a side effect you can cause what is called Port Stealing. This is happening when one IP is seen on two different ports of a switch. The IP is then assigned to the port the IP was last seen on which might be the port you spoofed the address from. But when the original host sends another package (which will happen frequently at least by ARP, IGMP,...) the IP is assigned back to the original port on that switch.

There is I think only one realistic scenario wich will put you in a position to sucessfully fake the IP-Address and also interact with the server.

Perform a MitM Attack between that hosts
Connect to that server with faked source address
Take the sequence numbers from the packets you receive for that original host
Drop the packets though they never reach the original host (apply this only to port 22)
Send answers with sequence numbers taken from source packet

The easiest way to do this might be through iptable rules. But "easy" should be seen in the context of this complex problem. I stronly encourage you to try this in a lab first!


Automated tools to test Struts OGNL security vulnerabilities I'm looking for a way to find Struts2 OGNL vulnerabilities (specifically http://www.cvedetails.com/cve/CVE-2013-4316/

and

http://www.cvedetails.com/cve/CVE-2013-2251/.  )

I know that attackers have such tools, and there is a Metasploit module for use when you already know the exact location of the flaw. What is a good method for finding web application pages vulnerable to these attacks (from a black box perspective)?  Also, are there tell-tale signs in the source code that an application might be vulnerable?

You can detect the use of known bad dependencies with OWASP Dependency-Check

I found this also looking for tools which attempt to exploit the known issues repetitively.  It's looking like I may have to modify existing active vulnerability scanners.


Is there any risk to having many "unused" ports open through firewalls and routers I have a server I am using to host public internet services where I want to start and stop many instances, lets say up to 50 per physical server. The architecture of the software means each instance needs its own port (unlike say HTTP where I could have a single Apache/NGINX/etc. then proxy requests to the right place based on domain name etc.).

Is there any security risk of making say 50 unprivileged ports (assuming I extend the software default port, this would be say UDP and TCP ports 35000 to 35050) permanently open in the systems and network firewalls, even when there is currently no instance running on that port? OR should I go to the extra effort to dynamically open/close the ports?

Does it matter that the software appears to default into the dynamic port range, or an unprivileged port (at least for Linux servers where low port numbers need root) in general?

This shouldn't be an issue unless a buffer overflow is found in the network stack. In that case, you are screwed if you have any ports open. However, the main purpose of a firewall is to prevent outsiders from connecting to services which should only be accessible to the local host (in the case of a host firewall) or to an internal network (in the case of a network firewall). Your particular case is that of a host firewall, and thusly there should be no effect on the machine of leaving the ports open other than that someone will believe that a program occasionally runs on those ports if they perform a scan (which is true, but trivial information in your case).

Therefore, no, you don't need to close the ports unless you are concerned about someone guessing that there is occasionally a service running on those ports and attempting to someone figure out when the service is running and on top of that develop an exploit for a piece of software they have no knowledge of.


Conceptual design of vulnerability scanning program in global retail network (PCI DSS) I am trying to design yearly program to scan for vulnerabilities on a very large network of payment terminals.

The company has thousands of retail points all around the world which need to be scanned for vulnerabilities. More specifically, we need to scan the credit card payment systems according to PCI DSS. While the terminals’ technology is somewhat standardized, there are firewalls in between, strong security policies and the systems might differ from country to country. The sites are connected to the servers mostly via ADSL, but some use phone and satellite.

The challenge is to identify cost-efficient alternatives for the scanning this massive network regularly.  Any ideas? I would appreciate the input, specially out-of-the-box. Please keep it on the conceptual level.

Thanks!

In the strictest sense the safest thing to do is to, of course,

As you've no doubt found this can be difficult in a distributed environment. The specific vulnerability scanning tool you use can also add in some problems. Take Nessus for example. When building a scan profile there is an option called, "Check for PCI-DSS compliance." This makes a bunch of internal changes to the scan profile to meet the muster they've defined. However, this also requires there be no network protections between the scanner and the device. So no firewalls, no IDPs, hell they don't even want any routers involved.

Going back to the conceptual level, keep these kinds of problems in mind as you're building out your infrastructure. Here are the design features that I would start with, presented as a bulleted list in no particular order.

Remote scanner housed at each site
Centralized system to pull reports from all remote scanners for processing
Vulnerability management process to

Review reports
Analyze results for false/true positives
Define actionable items
Prioritize items
Determine remediation/mitigation paths for each items

So yes, this type of a program comprises both technical and procedural aspects that must work in tandem. Additionally, the process for reviewing and handling the reports must include representatives from all involved units. Primarily whomever is involved in managing the endpoints, the terminals, servers, etc. May also include the groups responsible for managing the networking, internal customers outside of IT who actually use the system, or others as fit within your environment.


Is this a XSS vulnerability? I can't figure out why it's not working I was working on a web app and as I was building the front-end for a search function I tried to see if it would be vulnerable to XSS.

After pressing the search button, the js code will generate a paragraph with the search value and append it to the div, and when the paragraph exists it will just modify the innerHTML property.

After searching for  the paragraph looks like this
Searched:
.

I was expecting this to trigger an alert. I tried it in Firefox and IE.

my code:

<!DOCTYPE html>

<meta charset="utf-8"/>

    <input id="inputtext" type="text" name="search_value" placeholder="Search..">
    <input id="search_button" type="submit" value="Search" onclick="search_function()">

edit:I've added a snip of the source code

document.getElementById("results").innerHTML = label_results;

This is vulnerable to XSS. It interprets the label_results variable as HTML.

  var node = document.createTextNode(label_results);

This is not vulnerable to XSS. It interprets label_results as text.

  the paragraph looks like this
Searched:
.

Are you sure? Are you using the inspector in the developer tools of the browser? That can't always be trusted to correctly distinguish between HTML and text.


Why JSON Hijacking attack doesn't work in modern browsers? How was it fixed? I understand JSON Hijacking vulnerabilities have been fixed in all modern browsers, but how exactly?

There are many articles that talk about techniques to prevent JSON Hijacking attacks (i.e. prepending while(1); like Google does), but no one has explained if they still need to be implemented in a web application nowadays (obviously assuming users won't be using the app with very old browsers).

Should returning JSON data as array literals be considered a security risk nowadays?

The JSON issue that led google to prepend while was a same-origin breakdown in early versions of firefox (1.5 and 2b specifically) where the JSON file could be loaded as a normal script tag from off-site, and have its data reachable.

Normally JSON files don't "tell" the JS engine to do anything if loaded as a script, so they have/leave no reference to their data structures. JS's security is reference-based, so that assumption is fine. JSON Object literals ({})are actually an ambiguity to JS's engine since they look like code braces, causing those to syntax error. The problem with old FF was that one could use obscure runtime modifications that caused Array literals to execute some other code when parsed/created. That other code could introspectively reach the array's contents, which was a bug.

There were related issues with XML, as firefox considered some XML shapes to be valid JavaScript(tm) using FF's E4X extension (Ecmascript4XML). IE had some issues with non-js content being loaded as a script, erroring out, but revealing the contents to a pre-applied global error handler, which reported the source of the "code" causing the issue.

Since there are now viable safe ways of grabbing remote JSON content, the vulnerabilities of obsolete browsers and JSONp/eval() exploits no longer apply to loading content. If you try to load a valid JSON resource as a script, you cannot reach the contents from other JS.

Lastly, I don't think this actually has very much to do with security; php, curl, python etc don't give a hoot about the browser's rules; if data is out there it's out there. The only thing the same-origin policy does in that regard is prevent run of the mill "deep-linking" resource stealing of non-secret data.


Why aren't hardware SSH keys the default access for production systems? In the Bitcoin world I see people using hardware key stores (and hardware signing devices) as the de-facto only secure way of storing and transmitting $M values.

Wouldn't a hardware SSH keystore be the best way to go forward as well? I rarely see this option being promoted in any best practices and SSH hardware keystores (e.g. USB dongles such as Yubikey) seem to be a relatively niche market. Why is that route so unpopular?

Wouldnt a hardware SSH keystore be the best way to go forward as well?

Yes. In ideal world it would be best. But the requirement of the hardware and additional software handling the interface makes it less affordable. I would not say unpopular.

The most of the guides are for beginners to set up their first connection to github or to their first cloud box. In case you have a passphrase encrypted key, it is already very secure against offline attacks.

Using hardware device for private key operations should protect you against little bit more attacks (impossibility to copy the key, use it unauthorized), but you are not gaining much that would general user appreciate. Smart Cards are quite common in security-aware environments.


Should I use AntiForgeryToken in all forms, even login and registration? I'm running a rather large site with thousands of visits every day, and a rather large userbase. Since I started migrating to MVC 3, I've been putting the AntiForgeryToken in a number of forms, that modify protected data etc.

Some other forms, like the login and registration also use the AntiForgeryToken now, but I'm becoming dubious about their need there in the first place, for a couple reasons...

The login form requires the poster to know the correct credentials. I can't really think of any way an CSRF attack would benefit here, especially if I check that the request came from the same host (checking the Referer header).

The AntiForgeryToken token generates different values every time the page is loaded. If I have two tabs open with the login page, and then try to post them, the first one will successfully load. The second will fail with a AntiForgeryTokenException (first load both pages, then try to post them). With more secure pages - this is obviously a necessary evil, with the login pages - seems like overkill, and just asking for trouble.

There are possibly other reasons why one should use or not use the token in ones forms. Am I correct in assuming that using the token in every post form is overkill, and if so - what kind of forms would benefit from it, and which ones would definitely not benefit?

P.S. This question is also asked on StackOverflow, but I'm not entirely convinced. I thought I'd ask it here, for more security coverage

Yes, it is important to include anti-forgery tokens for login pages.

Why?  Because of the potential for "login CSRF" attacks.  In a login CSRF attack, the attacker logs the victim into the target site with the attacker's account.  Consider, for instance, an attack on Alice, who is a user of Paypal, by an evil attacker Evelyn.  If Paypal didn't protect its login pages from CSRF attacks (e.g., with an anti-forgery token), then the attacker can silently log Alice's browser into Evelyn's account on Paypal.  Alice gets taken to the Paypal web site, and Alice is logged in, but logged in as Evelyn.  Suppose Alice then clicks on the page to link her credit card to her Paypal account, and enters her credit card number.  Alice thinks she is linking her credit card to her Paypal account, but actually she has linked it to Evelyn's account.  Now Evelyn can buy stuff, and have it charged to Alice's credit card.  Oops.  This is subtle and a bit obscure, but serious enough that you should include anti-forgery tokens for the form action target used to log in.  See this paper for more details and some real-world examples of such vulnerabilities.

When is it OK to leave off the anti-forgery token?  In general, if the target is a URL, and accessing that URL has no side effects, then you don't need to include anti-forgery token in that URL.

The rough rule of thumb is: include an anti-forgery token in all POST requests, but you don't need it for GET requests.  However, this rough rule of thumb is a very crude approximation.  It makes the assumption that GET requests will all be side-effect-free.  In a well-designed web application, that should hopefully be the case, but in practice, sometimes web application designers don't follow that guideline and implement GET handlers that have a side effect (this is a bad idea, but it's not uncommon).  That's why I suggest a guideline based upon whether the request will have a side effect to the state of the web application or not, instead of based on GET vs POST.


Do you consider PWGen safe to use? Do you consider PWGen safe enough to use? What do you use to make truly random password. PWGen should be using "movement of your mouse" to make it really random, right?

The pwgen is a password generator developed by Theodore Ts'o, that is same person who create the /dev/random, and /dev/urandom for the Linux kernel.

  randomness

pwgen will seed from /dev/urandom, or /dev/random if they are available on your system.  See randnum.c.  I don't have refs, but I am very confident that /dev/*random has been reviewed for security problems.  Since it is critical too, and used by almost every cypto program on a typical linux system.

  Backdoors

The source code for pwgen is really pretty small.  I am not a security researcher by training, or trade, but I just can't see anywhere that you could hide anything like a backdoor, in a utility that simply returns a string of random random characters or phonemes.  There is no network access, there no writing to the filesystem that I see.  But feel free to look for yourself source.

  password strength.

I suspect the if an attacker knew you had used pwgen, and knew which options you used, and knew you used one of the options with the phonemes, then they might be able to brute force your password faster than if they attacker assumed your password that was completely random.  But that is true for most methods for generating passwords that people can actually remember.  Generating longer pwgen passwords should compensate.


Is it secure to have an "email no longer available" feature on your registration form? I was just implementing a new feature on the registration form of my site that checks if an email address is still available to register an account with. I am wondering if it is secure to show a user that a certain email address is no longer available.

Is this feature a security risk related to the privacy of my members and how can I use it while defending against bots looking for email addresses?

A way to implement the availability check without giving any feedback to potential attackers is to always send an email to the address used for the registration. What the content of the email could look like:

"An account for a@b.c [with username xy] was just registered at $site. Click here to confirm."
"Somebody tried to register an account for a@b.c  [with username xy] at $site, however this account already exist. If you forgot your password click here. If did not initiate the registration please disregard this email."

This way, only the real owner of the email address will be able to check whether the address has already been used to sign up for the service. This approach is for example used by Ubuntu One.


Can a neural network crack hashing algorithms? I've been reading a bit about neural networks, and their ability to approximate many complex functions.

Wouldn't a neural network be capable of cracking a hashing algorithm like SHA256?

For example, say we want to train our network to crack strings of 8 characters that were hashed. We could go through all the permutations and train the network since we know the inputs and expected outputs. Would the network technically be able to crack a relatively good amount of SHA256 hashes that map back to 8-character strings? Has this been done previously?

No.

Neural networks are pattern matchers. They're very good pattern matchers, but pattern matchers just the same. No more advanced than the biological brains they are intended to mimic. More thorough, more tireless, but not more sophisticated.

The patterns have to be there to be found. There has to be a bias in the data to tease out. But cryptographic hashes are explicitly and extremely carefully designed to eliminate any bias in the output. No one bit is more likely than any other, no one output is more likely to correlate to any given input. If such a correlation were possible, the hash would be considered "broken" and a new algorithm would take its place.

Flaws in hash functions have been found before, but never with the aid of a neural network. Instead it's been with the careful application of certain mathematical principles.


Why does openSUSE sporadically prompt during boot to trust its built-in certificate? The conundrum
My wife’s laptop has been running openSUSE Leap 15.0 for several years, and she has once or twice been flummoxed by this prompt at the very beginning of the boot sequence, most recently this morning:
Trust openSUSE Certificate

Do you agree to use the built-in openSUSE certificate to verify boot loaders and kernels?

This unusual behaviour has worried her, and left her uncertain how to proceed (especially as she could not use the mouse or most of the keyboard). The system appeared to boot quite normally when I selected Yes.
I should like to know why this happens, and particularly if it could be a sign of a security problem.
The system
The system (openSUSE Leap 15.0) has been in almost daily use for several years with frequent reboots without the above prompt; it has not been changed recently apart from installing updates, none of which I believe were installed since the previous boot. (I ought to get round to updating to a new version of Suse, but that is another matter!)
Sources consulted
I searched for the above prompt and found nothing that helped me much. I looked at:

SUSE and Secure Boot: The Details, a 2012 description of the boot process. This includes the following, which reassures me somewhat by describing a built-in key and possibility to override it, but does not explain the sporadic appearance of the prompt:

The shim then goes on to verify that the GRUB2 bootloader it wants to load is trusted. It will not use the SUSE KEK1 nor the Microsoft cert for this. In a default situation the shim will use an independent SUSE certificate embedded in its body. In addition, the shim will allow to “Enroll” additional keys, overriding the default SUSE key. Let’s call them “Machine Owner Keys” or MOKs for short.

1 Key Exchange Key “The Platform Key (PK) allows almost everything. The Key Exchange Key (KEK) allows all a PK can except changing the PK.”

This question in the Unix & Linux community. That includes the prompt but seems to have little bearing on our problem, being about subsequent problems getting an image to boot.

‘BootHole’ Secure Boot Threat Found In Most Every Linux Distro, Windows 8 And 10, at Forbes.com describing security problems in GRUB. This sounds scary at first, but I do not think it is relevant. After all, malware would hardly want to ask the user’s permission!

This is related to UEFI boot security. According to the OpenSUSE wiki, this should happen at first boot:

For the very first time of loading openSUSE 'shim', it asks the user
if the openSUSE certificate built in 'shim' is trusted to verify grub2
and linux kernels.

So this should happen only once. There was a recent security bug regarding UEFI boot security that may have triggered a refresh of the shim; this might have caused the message.