How exactly can an infected Samsung TV record private conversations in a room? We can read on Wikipedia page (about Weeping Angel) that Samsung smart televisions can be hacked by hackers which allows them to record conversations in the room and send it over the internet even if the TV appears to be off.
How exactly does the bug work and how can I know whether a specific Samsung smart television model is safe from this exploit?

A partial answer:

  Which models are safe

All models which don't have any microphones built-in.

  How this bug exactly works

The how is easy. If your TV has a microphone (for example your remote might have one to enable you to control the TV via voice recognition),
an attacker can turn on the microphone, record everything that it picks up and send it to a server on the internet where it can be picked up by an attacker. This is the same kind of attack that can be done on smart phones, except that there an attacker can also turn on the camera without your knowledge. This is why some people put a tape over the front camera of their smartphone and the builtin webcams of their laptops.

While André's suggestion not to connect the TV to a network might not be practicable, it's really the only way to be sure that your TV doesn't spy on you (the microphone recording is the biggest problem, but the TV can also spy on you by recording what you watch and when you watch it). I'm pretty sure netflix does this as a normal part of their business.

Another solution, if you're not afraid of operating on your TV set, would be to physically disconnect the microphone.


Checkpoint NGX IPS & NAT how does CheckPoint R65/R70 handle IPS violations of outbound traffic from hosts that are NAT'ed? Is it necessary to include the NAT'ed IP in the exceptions list or is it sufficient to include the private IP address?

Regards

Assuming that you are running IPS and FW-1 blade on a single system, rather than as standalones.  Also assuming that the NAT rules are part of the same FW-1 enforcement module that the IPS is running on.

The packet will enter the firewall kernel, be processed for SecureXL/ClusterXL/CoreXL, state table check, blah blah blah, go up the chain, be evaluated against security rulebase, which would determine if IPS inspection is neccessary, then processed down the chain outbound ... NATS applied, encrypt/log, and send to the OS for routing.  So the IPS would check on the untranslated IP.

I'm going to double check my SE materials when I get home but I'm 99% sure on this.

For sure 'fw ctl chain' will show you the processing order of all your FW-1 components.  what you would be looking for is that it is passed to IPS before it leaves "FW VM Outbound" (which would be with NAT rulebase applied).

Footnote:  The IPS architecture is actually different in R65 and R70.  R65 is the old SmartDefense and R70 IPS comes from the acquisition of Network Flight Recorder and the integration of that technology.  The <=R65 method of determining if a packet requires NAT is with rules (service definitions) in the security rulebase.  With R70, you have your own IPS rulebase.


Is a password protected PDF file safe for bank statement attachments? My bank emails my monthly statement to me in a password protected PDF attachment. Is this a secure method of transmitting something as sensitive as bank statement?

No, the use of a password protected PDF file is simply not good enough for sensitive data.

As others have already stated, newer version of the PDF standard use much better encryption methods than they originally did, however, a password on a file (even a strong one) will always be susceptible to brute force attacks. At this point you're just hoping their computer is slow enough that by the time they crack your (hopefully strong) password, the information is irrelevant. That's a lot of 'hopefully-s.' Assuming monthly bank statements, and a password under 50 characters, the security of your documents is starting to sound almost laughably naive.

This could also create a security risk in other ways depending on where the bank gets the password. I know of a bank that does something similar to this and uses your account password to encrypt the document, so that you only have to remember one password. This means they are storing your account password on the server. It may be encrypted, and it may not be, but either way it's probably safe to assume that any attacker that manages to break into your banks server and get a database dump now has your password. There is no excuse for saving passwords as anything but salted hashes (the same bank emails you your password if you forget it... yup, in a plaintext email).

If you can, call your bank and ask them to start sending you your statements encrypted using a public key system. PGP and S/MIME are both great, and will put a bit more security in your hands (it will be your job to protect your private key, not your banks).

Many banks also provide RSA tokens (or equivalent technology) for relatively cheap. Although there have been some (serious) security breaches with RSA in particular lately, this is still a great addition to your account security if your bank offers it.


Can they tell which individual computer was torrenting on shared internet connection? I live in a shared house where multiple people use the same wi-fi (actually, there’s two: the normal frequency and 5GHz one). The internet is included in the rent. The other day I received a complaint from the landlord that he received a message from Shaw (the internet provider) that someone had been doing torrenting. This wasn’t me but can the land lord of internet provider identify which individual computer it was considering they are all connected to the same router?

Also, what are internet provider’s stances on torrenting? My understanding is torrenting in itself is not illegal. But downloading copyrighted material is. Is it likely the landlord received a notice about copyright infringement and not about torrenting in particular? Even though torrenting isn’t illegal, does internet providers try to block it because it’s hard on their system?

Out of curiosity, how do they know someone was torrenting? If relevant the landlord also complained about going over the upload limit (though my personal suspicion it was from those who used Skype a lot).

Consult Shaw's TOS and AUP  http://www.shaw.ca/terms-of-use/

He probably got two notices, one being a DMCA copyrighted material download and the other being that excess upload traffic was being used. This is common on cable systems where the upload channel involves shared resources and abuse affects everyone on the system

As to Who, Shaw doesn't really care who's behind the NAT, the complaint is against the IP address and it's up to the internal users to hammer it out or lose the service per the Shaw TOS/AUP agreement.


How does "traceroute over TCP" work, what are the risks, and how can it be mitigated? There is a utility called tcptraceroute, and this enhancement called intrace that is used just like a standard traceroute, but it works over TCP.

How is the syn flag in TCP used to achieve traceroute like functionality (when ICMP is off)
What information can be disclosed (or other risks)?
How can this be mitigated?  (routers, hosts, ...both?)

This has been described as similar to the nmap command when passed the -sS flag.  If this is accurate, what does it actually mean?

All the tracerouting tools rely on the following principle: they send packets with a short life, and wait for ICMP packets reporting the death of these packets. An IP packet has a field called "TTL" (as "Time To Live") which is decremented at each hop; when it reaches 0, the packet dies, and the router on which this happens is supposed to send back a "Time Exceeded" ICMP message. That ICMP message contains the IP address of the said router, thus revealing it.
None of the tools you link to can do anything if some firewall blocks the "Time Exceeded" ICMP packets. However, blocking such packets tend to break the Internet (because hosts adaptively change the TTL in the packets they send in order to cope with long network paths, and they need these ICMP for this process), so, on a general basis, the "Time Exceeded" ICMP packets are not blocked.
What is often blocked, however, is the kind of short-lived packets that traceroute sends. These are the packets with the artificially low TTL. If they are blocked by a firewall, they never get to die "of old age", and thus no Time Exceeded ICMP. For TTL-processing and the "Time Exceeded" ICMP, the type of packet does not matter; this occurs at the IP level. But firewalls also look at packet contents. The goal is to fool firewalls so that they allow the short-lived packet to flow (and then die).
Plain traceroute uses either UDP packets, or ICMP "Echo" packets, both kinds being routinely blocked by (over)zealous sysadmins. tcptraceroute instead uses a TCP "SYN" packet, i.e. the kind of packet that would occur as first step in the TCP "three-way handshake". That kind of packet is not usually blocked by firewall, at least as long as the destination port is "allowed". tcptraceroute will not complete any TCP handshake; it just relies on the ideas that SYN packets are not shot on sight by firewalls.
intrace goes one step further in that it waits for an existing TCP connection (it does so by inspecting all packets, à la tcpdump). When it sees a connection, and the user presses ENTER, intrace will send short-live packets which appear as being part of the observed connection. intrace can do that because it has seen the packets, and so knows the IP addresses, ports and sequence numbers. All relevant firewalls will let these packets pass, since they (obviously) allow the observed TCP connection to proceed. The short-lived packets are adjusted so that they will not disrupt the TCP connection (i.e. they are simple "ACK" packets with no data by themselves, so the destination OS will simply ignore them).

Edit: I notice that I did not answer part of the question. Here it goes: there is no risk. There is nothing to mitigate.
traceroute reveals IP addresses of routers involved in routing packets. IP addresses are not meant to be secret and are rather easy to obtain for attackers through various means (mass scanning comes to mind, but also searching garbage bags for printouts of network maps -- the modern fashion of recycling makes dumpster diving a much easier and cleaner activity than what it used to be). However, a relatively widespread myth is that keeping your addresses secret somehow ensures security. Correspondingly, many sysadmins consider traceroute as a serious breach, to be fixed and blocked as soon as possible. In practice, though, this is all baloney. If revealing a few internal IP addresses is a major issue, then this means that your network is doomed.
Worrying about secrecy of IP addresses is like triggering a major incident response plan because an outsider learned the menu at the company's cafeteria. It is disproportionate. Granted, having precise and extensive knowledge of the network infrastructure can only help attackers; but not in really significant amounts. Keeping IP addresses secret is not worth breaking connectivity through excessive filtering (for instance, blocking the "fragmentation required" ICMP is deadly for any client behind an ADSL+PPPoE link).


Why does IKE have two phases? Why does have IKE have two phases, two levels of security associations, two sets of authentication and encryption algorithms, two sets of options around lifetimes and renogiations?
It seems duplicative.
AFAIK OpenVPN doesn't have two different "tunnels" established.
What's the reason for IKE doing this?

The two phases part here is a bit of a separate matter to the rest. Those phases are just two parts of the handshake, and they're just logical separations between the initial identity validation, authenticated key exchange, and parameter agreement (e.g. modes, features, etc.), which make up phase 1, and the derivation and setup of the secure channel used for bulk data transfer, which is done in phase 2.
This is very similar to how TLS in HTTPS works - the handshake initially exchanges information about the identities of the parties and what protocol version and features they supports, agrees on what features should be used, and (usually) does an initial key exchange which is authenticated by the long-term key from the certificate (as in IKE phase 1). It then uses that exchanged key to derive the necessary parameters for the secure channel that the bulk data is transferred over, and initiates that channel (as in IKE phase 2).
The duplication of security associations is because of certain usage requirements, partly due to historical hardware and telecommunications limitations.
The most commonly given example is in a distributed cellular network, whereby one client device might be talking to multiple cell towers. Each cell tower has plenty of processing power, is powered from the grid, and has a (relatively) high bandwidth network connection to the other towers. Compare that with your average late-90s cellular device, which has little processing power, runs on a small battery, has very limited bandwidth to the cell towers, and might be moving between towers quite a lot. Instead of making the phone perform a complete new two-way IKE handshake with every tower it comes across, there are instead two unidirectional channels - one for the client to talk to the tower, and another for the tower to talk back to the client - each with their own security parameters. The idea here is that the cellular device can broadcast data on one security association which is shared between all towers, allowing any tower to decrypt it, whereas data coming back from each tower to the cellular device has its own separate channel.
The differences in supported features, lifetimes, and renegotiations are precisely because of this difference in functionality. The outbound channel from the cellular device to the towers needs to be able to work in a broadcast environment, but the inbound channel does not. The security properties of each channel are tuned so that they are most effective for the specific use-case, providing the most security possible given the requirements of the system.


Can Google Policy Profile remotely erase all data on the device? I'd like to configure my company's Google e-mail on my iPhone, however when enabling e-mail profile in Inbox, Gmail, Mail or any other app, the following Device Policy Alert is shown:

  To use Google apps on this device as ..., your organisation requires that you install a security profile to keep your data safe.

And on the next screen the Google Apps Device Policy Profile says:

  Your admin may enforce policies, configure settings, and remotely erase data on this device.

I would argue how allowing remotely erase data on this device keep my data safe, but anyway.

My question is, what are the security risks involved by installing above Google policy profile which warns me that somebody from the company may which I work for can remotely erase my personal data on my device?

In other words, is this policy profile applies only for the e-mail data (like restricting the removal option only for specific app) or any other data as well (like personal e-mails, contacts, files, pictures, etc.), where somebody can accidentally wipe out my whole device?

Related: How the device policy profile works, but it doesn't explain much.

The short answer is "Yes".

If the phone given to you is a "company phone", you must comply.

If this is your phone, as the message mentioned, you must contact your company IT to check out the actual policy enforced. This is something internal, there is no way to tell how far the policy is enforced.

Since mobile phone is cheap now a day, I suggest you get another phone for such "company usage". You don't need an active phone services for that phone, you can tether your current phone as WIFI access point to that phone to download email from time to time.


What is the effect on a domain when the secondary name server is compromised? I've heard of a case wherein the domain name of the secondary name server was expired and free to register.

Let's say example.com has two registered nameservers:

example-ns1.com (primary)
example-ns2.com (secondary)

The domain example-ns2.com is expired and free to register. If an "attacker" claims the domain name of the second name server.

Would that only affect example.com when the name server with domain example-ns1.com is offline?
Will the "attack" only work when DNSSEC was not (properly) implemented before example-ns2.com expired?

DNS resolvers choose the name server to obtain the answer from randomly. There is no difference between primary and secondary NS servers from this point of view.

If you have 2 NS servers and one is compromised in any way, there is roughly a 50% chance that the caching DNS server asks a compromised NS server. When it does and gets a spoofed reply (possibly pointing to malicious target), it will remember such reply and return it to all subsequent queries for the same DNS name until the TTL of the reply expires (which can be realy long, like several days, if the attacker is clever enough).

If the visitor of such site uses a properly configured, DNSSEC-aware recursive resolver (caching DNS server) and the example.com domain is signed with DNSSEC, he is quite safe.

The DNS resolver verifies the answer from authoritative name server against the DS records from the parent zone (in this case the .com zone). If the answer is spoofed, resolver returns and error (and does not cache the wrong answer). Only if the cryptography used for signing the DNS zone in question (or any of the parent zones) is broken or the secret keys are known to the attacker, only then he could spoof such DNS reply.


Best practice of deprecating old OpenPGP subkeys when migrating to a new subkey pair? I've been using GnuPG with an offline master + online subkey setup for a while now. All my email is signed with the signing-only subkey and encryption is done with the encryption-only subkey. The subkeys are 4096 bits. This setup works well, but I wanted to improve security so I got a Yubikey Neo.

Because the Yubikey only supports 2048 bit keys, I generated another pair of subkeys on a secure machine and uploaded them to the Yubikey. Now I have two pairs of encryption and signing subkeys on my keyring. GnuPG will use the newest suitable subkeys automatically, so my earlier set of subkeys is basically redundant.

I keep all the subkeys on my main offline keychain, but I don't want them cluttering up the keychain on my primary portable devices (laptop, etc). My plan is to also rekey the Yubikey often (at least once a year) so I'll have to deal with a growing list of superseded subkeys.

If someone sends data encrypted to one of my old subkeys, I'll have to dig out the offline keyring in order to decrypt it. This is quite a pain and I'd rather avoid doing so.

What's the best strategy for discontinuing use of old but still uncompromised subkeys? Revoke them? Set a short expiration date and wait for them to expire?

Exchanging Keys on a Regular Base

If you intend to switch subkeys on a regular base (for example yearly, as you proposed), setting an expiration date seems a reasonable thing to do. Unlike expiration, other OpenPGP users will realize an outdated subkey anyway (which will trigger them updating your key, to look for new subkeys). Creating new subkeys in advance might help distributing it, key servers need some time to spread updates (between seconds and a bunch of minutes).

Consider setting up a reminder in your calendar, I often experience people to forget about creating new subkeys. When using smart cards like the Yubikey, remember you cannot download keys created on the device, so consider creating them locally and uploading them instead.

Revoking old Subkeys

Revocation does not necessarily imply your keys are compromised. There's a flag to indicate your (sub)keys are simply superseded and shouldn't be used any more. Revoking a key instead of just forgetting about it will also prevent possible attackers from using leaked keys after a time (this will probably be the reason you want to exchange keys every now and then, so also revoke the old ones!).

Remember revoking subkeys is nothing complicated and does not have any negative impact on certifications you received or issued.

Deleting old Subkeys

I don't see a reason not to store revoked and/or expired encryption subkeys on your "daily-use-computer" any more. You will not be able to read old encrypted messages any more if you do so! Removing the old (private) signing subkeys is not a problem, as only the public key is needed for verification, you will not use the private key any more anyway.


What is this spam used for? Recently my secondary e-mail address was exposed by an incident, and soon I received this spam. What is this spam used for?

First of all, HTML parsing of emails you don't trust shouldn't be enabled, let alone javascript. It's a serious security risk! All major email client platforms or webmail platforms have options to disable html and/or javascript on mails.

Now on to the question:

It seems that it is part of the cookieinjector greasemonkey script found here: http://dustint.com/code/cookieinjector.user.js

This script is normally used to capture a value (a cookie copied from a wireshark capture) from the form field and inject it to the page its been running from.

Without further access to the code noone can say exactly what is going on by looking at the picture, but my guess is that it is somehow modified to capture values and send them to the attacker, maybe other cookies etc.

It would be nice if you can provide the raw html source of the email so we can check exactly what is going on.


Is the traversal permission in a Unix filesystem exploitable by itself, in the absence of any other permissions/ACLs? Scenario/question:

A unix directory tree has NTFv4 ACLs configured to allow an unprivileged account traversal on all dirs (but no other ACL granting further rights on any file/dir anywhere

In such a case, is it completely safe to universally grant directory traversal right to everyone (setfacl everyone@:x:d:allow /path_to_mountpoint or similar), or can this be somehow exploited even despite there being no other ACLs set?

I'm figuring that in the absence of any other permission/ACL allowing other rights, this should result in an absence of any right to read, modify or control any object traversed to. Thus the traversal right is valid but in practice it's utterly useless / sterile.

In this context I categorise "exploit" strictly, and even the ability to list files in a dir (that didn't have other additional ACLs set on it) would count as "exploiting" since it's more than just traversal.

In that sense, can bare traversal ACLs be exploited, or is this a "safe" right (including in the sense of file privacy) to give untrusted/unprivileged/guest accounts even on paths one doesn't want them to make use of?

Explanation/use-case:

I'm mainly thinking of a file server's data store on FreeBSD ZFS, but I guess it's similar on most unixes.

The use case is: suppose I want a specific unprivileged user to access only a specific nested dir within my data directory. Rather than setting traversal for that user on all parent dirs to reach that path, it would be administratively easier if it's secure, to

Grant universal traverse rights to everyone on the entire data dir, inherited to all dirs, but then
Control actual use/access/scanning by setting read/write/modify ACLs on files+dirs they are allowed to use, while setting no rights, or explicit deny rights, on every other ACL flag on all other dirs/files (other than just "x" on dirs).

If traversal can't be exploited, then the traversal right is sterile and useless unless combined with a target path/file that the user actually has some other ACLs for. But is that correct, or is it subtly loophole-y?

Granting traversal only (x permission on directories, and nothing else) doesn't let someone do much, but it does create some risks.

With x permission on directories, a user can check whether a file exists. Without the r permission on the directory, the user can't list files, but if they guess a file name, they can test whether there is a file by that name. This usually doesn't leak a lot of data, but it can be a privacy violation.

Beyond this, there is a risk that some file or directory inside the tree is not protected. It's pretty common to have world-readable files lying around. That's safe as long as they're under a directory that unauthorized users can't traverse. If you give traversal permission to everyone, then everyone can access those world-readable files. The same risk exists with world-writable or group-writable files.

Rather than give traversal permission to the toplevel directory, it's safer to expose selected subdirectories. As usual, it's safer to whitelist known public data than blacklist known confidential data. You can expose a subdirectory of a private directory through a bind mount. On FreeBSD, you can create a bind mount with nullfs (built in) or bindfs (FUSE).


LUKS2 on-disk format specifications The LUKS1 format has been available for a long time, and the format specifications are easy to find. Recently, LUKS2 has been released, which features a number of important changes, such as AEAD and Argon2. The release notes mention that the new on-disk format uses JSON for metadata. I would like to study the on-disk format but would rather not have to dig through the source code to discover the specifications anymore than I have to. Are there any resources which provide the on-disk format?

Update: A full specification PDF for version 1.0.0 of the LUKS2 on-disk format can now be found in docs/on-disk-format-luks2.pdf. (It's a permalink, so check the master for updated versions.)

It's in docs/LUKS2-format.txt.

They have a comment saying:

Note: these are temporary documentation notes only.
The more formal definition will be published later.

So a full comprehensive documentation beyond this file doesn't seem to be currently available.


OpenSSL key derivation I'm trying to manually decrypt DTLS packets sent by OpenSSL.

The cipher suite used between the server and the client is TLS_RSA_WITH_AES_256_CBC_SHA256 and my understanding is that the IV used by the cipher is prepended to the encrypted application data. I also know the master secret used by the server.

Now to my question, how OpenSSL derives the encryption key from the master secret ?

Meta: Doesn't add much to the dupe but on rereading I notice I missed the "D".

Key establishment and encryption/decryption and authentication processes for TLSv1.2 are specified in RFC 5246 TLSv1.2 plus for ECC key exchanges (not here) RFC 4492 TLS ECC as amended by appendix A.7 of 5246.
These processes also apply to DTLSv1.2 RFC 6347 DTLSv1.2, although the record headers, actual transmission and some error handling differs for DTLS compared to TLS.

SSL/TLS/DTLS key establishment has two parts: one which varies based on (only) the key-exchange algorithm used and produces a "premaster secret", and one which varies based on (only) the bulk-cipher and MAC algorithm(s)/mode selected and uses the premaster secret to produce a master secret and then the several working keys, IVs and nonces.
The encryption/decryption and authentication processes vary similarly.

For TLS_RSA_WITH_AES_256_CBC_SHA256 the key-exchange algorithm is RSA. The premaster secret is chosen by the client, RSA encrypted under the server's public key and sent to the server which RSA decrypts it and checks it. See in 7.4.2 the item for RSA, 7.4.7.1, and 8.1.1. To do this outside the server you need (a copy of) the server's private key.

The premaster secret is then used with the nonces to derive the master secret as specified in 8.1 using the PRF (PseudoRandom Function) defined in sec 5; this is then used again with the nonces to derive working keys as specified in 6.3 using the same PRF for the sizes in appendix C. For TLS_RSA_WITH_AES_256_CBC_SHA256 the cipher is AES_256_CBC which requires a key of 32 octets in each direction and the MAC is HMAC-SHA256 with a key of 32 octets in each direction.

Each data record is MACed and encrypted by the sender, and decrypted and verified by the receiver. The MAC/verify process is specified by 6.2.3.1 (for all non-AEAD ciphers/suites, and this suite is not AEAD) and the encryption/decryption process for CBC-mode (block) cipher is specified by 6.2.3.2; it does indeed choose a per-record IV and prepend it to the encrypted record data.

For another ciphersuite the outline is the same but in some places different specific sections of RFC 5246, and for ECC-based key exchange (ECDH, ECDHE, or ECDH_anon) RFC 4492, apply.


Opening mail without any risk Before opening unknown email (not in spam folder) how we can identify no any danger inside the mail (with availability of active virus guard)

To be safe from having mails that possibly harm your system through an attack you first need to know what attacks you want to be protected against.

Mail body Attacks (like malicious HTML inside the mail) Protection options are

Open Mail in plain text mode, in this mode None of the text is treated as having special meaning and is just show on the screen, in case of an HTML document you do need to be able to read HTML to understand your mails.
Set the mail client to NOT display Images. Images have been used as a means of infecting a system through several means. some involve maliciously crafted images that exploit the viewing system, some that employ Track and Trace for scouting new locations to attack.
Disable JavaScript. Some people think that disabling the JavaScript inside mails can protect you. while it does offer a slight barrier in my opinion, I do believe not running any of the code is better. so reading HTML ;)

Attachments Attacks (Like malicious Zip files) Protection options are

Disable Attachments inside the mail server. Hardly a user friendly option.
Have a virus scanner integrated into the mail server. solves known viruses but does not protect against directed attacks or new virus (types)
Simple NEVER EVER open an attachment unless you specifically asked to be mailed one. (good policy in my opinion.) Mails are most often the most effective when there short and to the point. you do not need to send a big blob of data to do that (like a document)
Save attachments and run the virus scanner over them before you view them. same protection as doing this server side with the added bonus of someone consciously doing the task and understanding that there are risks.

In short none of these methods offer a foolproof method of protection or are complete in any way. just use common sense and understanding of how the "bad guys" work go a long way.


The hidden meaning of the source code of the malware? I'm studying the source code of malware developed in c++ and I have two questions in the source code below
This is probably code that loads malicious dlls into memory.
typedef BOOL (WINAPI *VirtualFreeT)(
    __in LPVOID lpAddress,
    __in SIZE_T dwSize,
    __in DWORD dwFreeType
    );

char dllA[] = {'K','E','R','N','E','L','3','2','.','d','l','l','\0'};
char dllB[] = {'V','i','r','t','u','a','l','F','r','e','e','\0'};

VirtualFreeT pVirtualFree=(VirtualFreeT)GetProcAddress(LoadLibrary(dllA),dllB);

_asm nop;
_asm nop;
_asm nop;
_asm nop;
_asm nop;
_asm nop;
_asm nop;
...
..
.

Why not declare the name of dll as below?
Is it just a certain insertion of a null char?

char dllA[] = "KERNEL32.dll";
char dllB[] = "VirtualFree";

It doesn't do anything. Why need this code?

_asm nop

Why not declare the name of dll as below? Is it just a certain insertion of a null char?

No, these two lines of code create identical null-terminated strings in the resultant binary:
char dllA[] = {'K','E','R','N','E','L','3','2','.','d','l','l','\0'};

and
char dllA[] = "KERNEL32.dll";

Perhaps the malware author believed there was a difference, but more likely, it's a style choice only.

It doesn't do anything. Why need this code?

It's almost certainly a NOP Sled.  When placing a buffer overflow, it may be difficult to calculate exactly where the instruction pointer will land.  By preceding the meat of the overflow code with a series of No-Op instructions (which do nothing) that instruction pointer can slide smoothly along until it reaches the exploit code, as long as it lands anywhere in the NOP Sled.


How well can Tor + VPN secure my anonymity on the internet? I want to be as anonymous as possible online without anyone being able to connect me to my online activity. Assume that the people trying to track me have lots of resources and can even use the legal system against me. In essence, assume the United States Government is trying to track me.

I know Tor and VPNs provide anonyminity. Will the combination of these protect me? Would someone be able to find my VPN from Tor, and then from the VPN find me? Or am I actually secure? Can I remain anonymous from the government of the United States of America?

No. Just installing Tor and a VPN does not make you safe. Even if Tor was resilient against attack and VPN was secure and trustworthy, they would only mask your IP. Many people using Tor were caught, not because Tor was defeated, but because they made a mistake. They logged in to a social network or used it on a school computer or had cookies in their browsers or allowed javascript/adobe flash player to reveal their IP and many more. Being completely anonymous against the government of the United States is an open problem. Even if there was a way, there would be no way to show, if it really works or not.


What is a good browser for web application pen testing? I am getting started in testing web applications, and I am having trouble verifying vulnerabilities.

It seems all modern browsers have protections against things like XSS.

When something like Burp finds an XSS vulnerability, I can't ever verify it when using something like TamperData. The code gets sent to the page, but it never seems to execute.

Is there a browser that specifically allows things like XSS and CSRF to execute, for the purposes of testing?

Most browsers allow you to disable the function. For instance with chrome you need to start the browser using

C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --args --disable-web-security

For Firefox you have to go type about:config in the address bar. Then you need to set the browser.urlbar.filter.javascript to False.

For Internet Explorer click Tools–>Internet Options and then navigate to the Security Tab. You need to set a custom security level. Scroll towards the bottom where you will find that Enable XSS filter and disable it.


When using keyfiles with TrueCrypt how does the file size and/or number of files affect the difficulty of breaking into the container? I'm looking at setting up an encrypted container with TrueCrypt (surprise) but I'm not sure whether I should use multiple files or if a large file would make any difference.

Does the file size or number of files matter beyond the fact that you would for example need a larger file or have access to all the key files?

According to the Truecrypt documentation, only the first 1MB of contents in the keyfile is actually examined. So anything beyond that is totally superfluous.

But more interestingly, keyfiles are simply hashed (along with other keyfiles and any password) to produce the real key. As such, the real key length is limited -- as of course it would have to be.

The length of the hash output depends on the hashing algorithm, but the important point is that no matter how much entropy you put into the hash, the amount you get out is capped at the hash size. The result is far larger than could possibly ever by brute-force cracked, so that's not a concern. But if you're using truly random keyfiles, then just a few bytes (say 64 characters) is typically enough to hit that entropy cap. Anything beyond that is just further permutation of the same bits.

Again, you choose the hash type, and SHA-256 and SHA-512 are common candidates. As for how easy it is to brute-force crack a 256-bit key; it's impossible beyond the laws of physics.


How can a weak root password be compromised? I use ubuntu for personal computing. I've read an advice in many questions here to have a strong root password. I don't understand what's wrong with a weak root password. After all we have to type root password number of times, and it's inconvenient to type strong password time and again.

What can be the possible threats if I use a not so strong root password?

Short passwords are prone to easy shoulder surfing and brute force. If you are sure that all services which can be accessed remotely are off, feel free to keep short password. Also, make sure you are not storing any valuable, sensitive or confidential information on such system.

The point is to make the password cracking effort so hard that to compromise it will possibly take enough time and resource than the value of information stored on the system or till that time password will expire or is changed. However, given the power of cloud, now brute forcing something has become cheaper.

P.S.: I felt like putting the comments as answer.


What defines a CSRF vulnerability? As a part of my position at the company I am employed with, I manually penetration test our web application (still in development) for vulnerabilities. While testing, I attempted to see if our web application was vulnerable to CSRF. To do so, I ran the application in tab A and authenticated with the web app. In tab B I opened the JavaScript console and ran:

window.location.replace("http://privilegedLocationInWebApp.com");

The redirect was successful, directing tab B to an authenticated page within the web application.

Later in the day at home, I decided to play around and see what other sites are vulnerable to this as it struck me as something that is probably frequently overlooked and testing it causes no harm to the webpage (i.e. I am not trying to SQL inject them or do any damage). Attempting such a redirect on a non-authenticated tab with a separate tab already authenticated was successful on multiple sites, a few seeming to be a little too important to allow such a vulnerability.

Is this really a CSRF vulnerability? Or is this simply overlooked by owners of websites and web apps since these requests are all GET requests but an attempt to do a POST might be rejected as that would symbolize a true CSRF vulnerability?

There are a number of misunderstandings here:

Tabs can not be "authenticated" or "unauthenticated". If you are using cookie based sessions for authentication, it is the presence of the session cookie that gives you access. That cookie belongs to the browser session, and not to a specific tab.
Loading a "priveliged location", i.e. a page that an unauthenticated user should not have access to, is not proof of CSRF.

The victim could itself just open a new tab, enter the URL to the priveliged location, and have access to it, right? All you have done is to do this with a bit of JavaScript. How could you, as an attacker, leverage this? You couldn't! The browsers Single Origin Principle would stop you from reading any data, and you didn't trick the server into performing an action.

So what would consitute proper CSRF? For this to be useful, you have to get the server to do something - create a user, delete a post, change a setting, whatever. As you say, this would normally require a POST request, but on a poorly designed page it might be possible with GET as well. Anyway, that is what you should be looking for!


Why change a salt when the password changes? If a salt is just a random string of characters anyway, what is the purpose of changing the users salt each time they change their password?

From a coding perspective it's actually harder and less efficient to get the existing salt and re-use it than it is to just generate a new one.  Using the old salt requires a round trip to the database or file, and requires extra complexity and code maintenance over simply creating an entirely new salt+username combo, which you have to have code for when the first password is set.

In other words, it's easier, faster, and safer to just use the same code you already have that creates a new salt, so why do anything else?  From a security perspective, less code to maintain is more secure.


Does applying updates fix router vulnerabilities? I just found some vulnerabilities (CVE's) on my device at an firmware version. If I apply the update is it enough to solve the problem?

It's about DIR-600.

In case of DIR-600 yes ... but that is not always right!
In you case dir-600 was checked and re-checked because is an outdated router that was commonly available for everyone.

It really depend on the product and I strongly recomand to check the official CVE page of the device to see if the last firmware version has any cve.


Is a reverse proxy worth it? Is a reverse proxy worth it?  There are so many unsecured sites using a reverse proxy and I feel like that doesn't protect them.  After all if they have an error in their SQL that could be use for injection, right?  I feel like too many people rely on reverse proxy without knowing how to program correctly

I'd like to first specifically comment on this statement -

  "There are so many unsecured sites using a reverse proxy and I feel
  like that doesn't protect them."

Just because you see some site is using X or Y CDN/WAF, it doesn't mean they have some/any security.
Some use free/cheap-tier plans that offer partial security, and others don't turn ON certain WAF features (even if paid for).

Like any security measure, virtual or physical, Web Application Firewalls (via reverse proxy or any other deployment format) aren't a silver bullet.

It doesn't mean you shouldn't use them, on the contrary! Using a proper Cloud WAF helps you avoid very common pitfalls many websites suffer from:

3rd-party code - You might be writing some kick-*** code, but what
about the 3rd party libraries you use? What about servers running
WordPress/Joomla/Drupal/Magento/…?

You can't be responsible for every piece of code that your system runs, and time-to-patch is critical.  A proper Cloud-WAF provider gives you virtual patching that’s magnitudes faster and more reliable than a panicking siteop.
Lower-level vulnerabilities - Remember Heartbleed? Shellshock? POODLE?

How long does it take you to deploy OS-level patching? In
some cases, if it's more than a couple of hours, good chances you're
compromised.
DDoS Mitigation - Hopefully everybody understand by now, that you can only completely mitigate DDoS using a cloud scrubbing service.
(And no, AWS is NOT a scrubbing service).
Filtering out abusive visitors - Comment Spam, Referrer Spam, Scraping, etc.

Things that, unfortunately, have anything to do with
your ability to "program correctly". Cloud-sourced client
classification and reputation gives you that.
Security at the edge – Not only content caching! You can offload many heavy-lifting and hassles to the edge.

Want to require 2FA and/or CAPTCHA on certain pages? Deliver them from the edge.
Want to block certain IPs? Filter at the edge.
Don’t want visitors from outside the UK? Filter at the edge.
Don’t want Firefox from Iran accessing /login more than 5 times per minute? You guessed it, Filter at the edge.

That’s just to give you a taste, there are many more great things a CBSP can give you (we haven’t discussed visibility at all).

Disclosure: I work @ Imperva Incapsula, a CBSP which provides Cloud WAF/DDoS Mitigation/CDN/GSLB.


Are Meltdown and Spectre complementary and used together Meltdown and Spectre have both been announced at the same time, almost always in the same sentence. Is there a connection, other than timing and the fact that they attack chips? Are they used together in tandem to exploit a system? Or is it just coincidence that they were announced at the same time?

These are all attacks in the same area, i.e. using side channels during speculative execution in CPU's. It is not uncommon that if you find one problem you look deeper and find even more problems in the same area.


Postfix master running as root Does running /usr/lib/postfix/master as a root could cause a security threat ?
A fresh installation, gives this  :

root     11622  0.0  0.0   4792  1432 ?        Ss   19:11   0:00 /usr/lib/postfix/master
postfix  11624  0.0  0.0   4812  1324 ?        S    19:11   0:00 pickup -l -t unix -u -c
postfix  11625  0.0  0.0   4856  1344 ?        S    19:11   0:00 qmgr -l -t unix -u

The Postfix master process is the one that launches the other daemons. In particular, it launches the daemon that delivers mail locally; the latter must be able to impersonate any user ID in the system, which involves beginning its life as root. Thus, it is mostly unavoidable that the master process runs as root; otherwise, it would not work at all.

Moreover, the "risk" involved in running things as root is often overestimated. For instance, on my own server, what I fear most is that my machine would be subverted and used as a relay for attacking other people. Whether an attacker gains root access or only a "normal user" access does not change things much in that respect.

There is a widespread habit of turning root daemons into non-root daemons, and then to rejoice at the "security improvement". The improvement is real in the mainframe scenario, where many users have shell accounts on the same machine, and the attacker is one of these users, intent on gaining access to the files of other users. However, the mainframe model has mostly disappeared (it used to be prevalent in universities, but nowadays every student has his/her own computer to play with). When machines are "personal" (e.g. you have your own server and no hostile individual has an account on it), the benefits of running some daemons under a non-root UID are slight. It does not harm by itself, but it does not justify going out of your way in complex ways to "fix root daemons".

What makes Postfix daemons secure is absence of buffer overflows or similar vulnerabilities; running as non-root is simply a way to mitigate consequences in case a vulnerability was present and exploited by an attacker; and the mitigation does not gain much when the machine is not a shared mainframe.


Two factor authentication(Mobile) Consider such two factor authentication on web site: say when user enters username/password on web site - and receives SMS on mobile phone number. For attacker to access this he must know your username/password - and also steal your mobile phone.

But if I want to protect mobile phone application this way, I think the second factor is not useful anymore. Because in order for attacker to access your mobile phone application, she has to steal the phone anyway - now if she stole it AND knows user name and password he can access your mobile phone app.

So I think the two factor authentication scheme I described above doesn't bring much security when used for mobile phone application; Of course that is not the case if you use this method for authenticating with web site. Am I right?

So what second factor is typically used to protect mobile phone applications? (besides password).

The point of two-factors authentication is to pick two of the following:

something you are (biometrics, ...)
something you know (password, pin, ...)
something you have (token, phone, ...)

If you want to protect something that is locally store on a phone, you obviously don't ask for the user to have the access to the phone. You can still use 2-factors authentication by either choosing a "something you have" that is not the phone (example a token), or switch the criteria to "something you are" (example fingerprint). For some reasons, the biometrics are not necessary the best way to go, because it generates some problems.

Eventually, some have tried to use new criteria like "someone you know", for example by issuing a token from an already authenticated session, to connect a new device. Mozilla Firefox did that for a time to synchronise the preferences between browsers.


How can SMS spoofing be detected? SMS spoofing involves faking the source ID, by replacing it with alphanumeric text. This can be useful for mobile providers, but can lead to security issues such as social engineering. How can we as users, or the providers themselves, detect illegitimate SMS spoofing?

The best way to detect if the message was spoof or not is to check the message-center. Normally, a spoofed source will have the message-center shows different gateway from the network of the gateway where the originating source is.

Ex.

Spoofed ID: VERIZON
Message-centre: +927566004455

Original ID: VERIZON
Message-centre: +181800001111

got it?


How to spoof my IP address to JavaScript and other security concerns Many websites require JavaScript. However, enabling JS means that a website can run a JS snippet to retrieve the user's IP address (even if they are behind a proxy or VPN).

So, how can I (the user) feed (spoof) the VPN IP address (which I have in a text file) to any JS that might run so that it all looks the same to the web server?

Edit / Addition:  after doing a little research, i came across this site http://mybrowserinfo.com/detail.asp?bhcp=1  that displays a bunch of info that my browser is sending to the web server (Browser version, local time, screen and browser dimension, connection speed, ect..).  This combo of info allows a malicious authority (say, the Chinese govt) to "fingerprint" the user, even if they do not have the IP address (because the user is behind a VPN and WebRTC has been disabled).  How do i disable or "clean" this information, such that the web server can't identify the user?  Is this all from WebRCT?

I suspect some of this info is coming from the UserAgent string, which i suppose the user could manually change, but what about the rest?  Some must be coming from javascript, no?

So, how can I (the user) feed (spoof) the VPN IP address (which I have in a text file) to any JS that might run so that it all looks the same to the web server?

The detection of local IP addresses you refer to depends on WebRTC. There is no way to spoof the addresses returned during the WebRTC discovery without changing either the browser code or configuration or the script which is used for discovery. You could

switch off WebRTC completely, either by using a browser which does not support it (like Tor browser bundle) or by disabling it using various methods
try to make a script which somehow interferes with the discovery in the Javascript code and report something different. But this script needs to be probably adapted to various sites.

Simply disabling WebRTC is probably much easier than trying to report different values to the server.


Alternatives to Common Password Retrieval Wired wrote an article recently about the top tech fails of 2012 and to no surprise, the password was on the list, more specifically the way a user can retrieve their passwords.

What are some nifty alternatives to the classic "reset your password through email" method? I haven't really seen anything else implemented, and the things I have seen, aren't very friendly to the common computer user and often involve a lot of steps that get users frustrated.

Please provide some examples of sites that use alternatives! I'm interested :)

Authentication is made by using one of these or their combination:
1- Something you know (Text passwords like everywhere!)
2- Something you have (Tokens, Smart Cards etc )
3- Something you are  (Eye's Retina, Finger Print etc) .

All these methods have their own weaknesses in their nature.
Combining them helps but it also deceases ease of use & availability.
Passwords weakness is that it can be changed without identifying the one who is doing this.
It's vulnerable in it's nature.
Of course your can combine it ie. reset password after verifying finger print or ID card, thinking to availability & normal users, it's actually useless.

Anyway, Personally i rather to answer to my security questions to reset my password, mainly because my answers are like passwords more or less, unguessable & badly typed !

Q:what was your favorite childhood cartoon?
A: h0w d0 u kn0w if i ever w@tch3d 1?


Predictability of PHPs array_rand It's generally known information that methods such as the array_rand() method in PHP are not considered cryptographically secure. I'm trying to understand under what situations generated result may be predictable.

If I know the seed, the values in the array, a single generated value and how many times the method has been called before that value was generated, I know I can easily calculate all subsequently returned values. I can do that by writing my own script that uses the same seed and generates the same number of results, thus putting it in the same state.

Assuming I don't know the seed or the number of previously generated values, what are my chances/how low can I get the probability of predicting future values.

To define a more concrete example and make the question less theoretical, lets assume we're using array_rand to generate case-insensitive alphanumeric tokens with a length of 12. This is done by grabbing 12 values from a character array by calling array_rand 12 times thus making the token [A-Z\d]{12}. I know I have one of a thousand consecutively generated tokens, but not which position it was generated in.

Can I predict the next token (assume I've not got the last token generated)? I'm assuming this can't be predicted with 100% accuracy, but what are the chances of brute forcing all possibilities for the next token, and how many would there be?

Assuming I can validate if a token is valid, how much does knowing 2 consecutive tokens (24 values) narrow my chances of predicting the 3rd, etc.

I've seen some research on cracking the state of rand but the articles generally don't deal with constrained/truncated ranges.

P.S. I'm trying to understand the proof/math behind why it's insecure, not looking for suggestions of more secure approaches.

array_rand calls mt_rand internally. This is a Mersenne twister algorithm with a state size of 624 numbers. This means that if you get 624 consecutive outputs of mt_rand, you know the whole state and can predict all future numbers.

As you correctly indicate it is pretty hard to obtain the output of mt_rand in real-life cases, because it is typically limited to some range. This is not necessarly a problem for the attacker: if the application calls mt_rand(0, 8) the attacker only knows three bits of the state, but he also needs to predict only three bits to predict the algorithms output.

Another practical problem with cracking PRNGs is that the attacker needs to request tokens from the same process, because different processes have different PRNG states. Typically when you connect to a server the request gets handled by a random process. You can do up to 100 requests on one connection, but this is still short of the 624 requests you need to get the state of mt_rand.

In your example you call array_rand 12 times, so the attacker does not get any intermediate output of mt_rand. There are too many combinations here to brute-force.

So this could be practically secure, but it would be risky. One application I looked into also used mt_rand for token generation, and then had another page that called mt_srand(). This made it possible to seed the PRNG with a known value. I also wrote something about cracking the PHP PRNGs, although it does not go into mt_rand state cracking.


Secure way to inform user of their new password We have an IBM z/OS system that I am part of the administration team on which we often have to reset users' passwords. (forgotten, too many violations etc).

We do this my choosing a new password and assigning it to their id. We then email the user with their new password.

I know this is bad but am uncertain how we can improve the process?

My current idea is to provide a website which can produce a public and private RSA key pair, have them send us the public key which we then use to encrypt their new id and which they can then decrypt with the relevant private key.

What is the recommended process for systems whereby passwords resets are a manual process and the new password must be given back to the user?

Edit:

The OS is z/OS, the security system is ACF2 and changing a password is done via a CLI-type interface, where an authorised user simply issues a 'change' command with the userid and the new password in cleartext.

the email informing the user of their new password is done via internal mail, but will often be sent internationally. The user will have to change their password upon first use.

Based on discussion in the comments, I would suggest a

one-time link, that links to web page displaying the new password to the user.

Some upsides of this:

Transmitting the actual password happens (/should happen) in HTTPS.
The password is only ever exposed in the browsers cache and server-side. (This means that future breaks on a clients device will not leak the password)
You can use further authentication methods on the web page, which will ensure that the new password is kept secret.


How do organizations check *what* has been hacked? In the UK, the company TalkTalk was recently hacked.

It was later discovered, after 'investigation' that the hack was not as serious as it could have been (and less than expected).

I'm wondering: How do organizations (not necessarily TalkTalk -- that's just what prompted me to ask) check what has been hacked? I'm sure there are many ways; but what are the 'main' ones?

In a word: Forensics.

Computer forensics is the art of examining a system and determining what happened upon it previously.  The examination of file and memory artifacts, especially file timelines, can paint a very clear picture of what the attacker did, when they did it, and what they took.

Just as an example - given a memory dump of a Windows system, it is possible to extract not only the command lines typed by an attacker, but also the output that they saw as a result of running those commands.  Pretty useful in determining impact, eh?

Depending on the freshness of the compromise, it's possible to tell quite a lot about what happened.

@AleksandrDubinsky suggested that it would be useful to outline the various Computer Forensic fields and techniques, which I'm happy to do for you.  They include, but are not limited to, the following (I'm going to use my rough terms; they aren't official or comprehensive):

Log/Monitor Forensics: The use of 'external' data such as centralized logs, firewall logs, packet captures, and IDS hits straddles the line between "Detection" and "Forensics".  Some of the data, like logs (even centralized) cannot be trusted to be complete or even truthful, as attackers can filter it or inject it once they have control of the system.  Off-the-system packet logging tools like the firewall, IDS, or packet recorders (such as (formerly)NetWitness) are unlikely to be tampered with, but contain only a limited amount information; usually just a record of IP conversations and sometimes signatures (such as HTTP URLs) associated with malicious activity.

Unless an unencrypted network connection was used in the compromise, these tools are rarely able to detail the activity during a compromise, and so (going back to the original question) don't "check what has been hacked."  On the other hand, if an unencrypted connection (ftp) was used to exfiltrate data out, and full packets were recorded, then it's possible to know exactly what data the attacker ran away with.

Live Forensics:  More properly part of Incident Response, so-called "Live" forensics involves logging into the system and looking around.  Investigators may enumerate processes, look in applications (e.g. browser history), and explore the file system looking for indications of what happened.  Again, this is usually designed to verify a compromise happened, and not to determine the extent of a compromise, since a compromised system is capable of hiding files, processes, network connections, really anything it wants to.  The plus side is that it allows access to memory-resident things (processes, open network connections) that aren't available once you shut the system down to image the disk (but, again, the system may be lying, if it's compromised!)

Filesystem Forensics: Once a copy of the disk has been made, it can be mounted on a clean system and explored, removing any chance of the the compromised operating system "lying" about what files are in place.  Tools exist to build timelines using the variety of timestamps and other metadata available,
incorporating file data, registry data (on Windows), even application data (e.g. browser history).  It's not just file write times that are used; file read times can indicate which files have been viewed and also which programs have been executed (and when).  Suspicious files can be run through clean antivirus checkers, signatures made and submitted, executables loaded into debuggers and explored, "strings" used to search for keywords.  On Unix, "history" files - if not turned off by the attacker - may detail the commands the attacker entered.  On Windows, the Shadow Copy Service may provide snapshots of past activity that has since been cleaned up.

This is the step most commonly used to determine the scope and extent of a compromise, and to determine what data may or may not have been accessed and/or exfiltrated.  This is the best answer to how we "check what has been hacked."

Disk Forensics: Deleted files disappear from the filesystem, but not from the disk.  Also, clever attackers may hide their files in the "slack space" of existing files.  These things can only be found by examining the raw disk bytes, and tools like The Sleuth Kit exist to rip that raw data apart and determine what it means about the past.  If there was a .bash_history file, and the attacker deleted it as his last step before logging out, then that file may still exist as disk blocks, and be recoverable.  Likewise, attack tools that were downloaded and temporary data files that were exfiltrated can help determine the extent of the compromise.

Memory Forensics: If the investigator can get there soon enough, and get a snapshot of the memory of the system involved, then they can thoroughly plumb the depths of the compromise.  An attacker must compromise the kernel to hide from programs, but there's no way to hide what's been done if a true image of kernel memory can be made.  And just as the disk blocks contain data that has since been removed from the filesystem, the memory dump contains data that was in memory in the past (such as command line history and output!) that has not yet been overwritten... and most data is not overwritten quickly.

Want more? There are training programs and certifications to learn Forensics; probably the most common publicly available training is from SANS.  I hold their GCFA ("Forensic Analyst") certification.  You can also review the Challenges from the Honeynet Project, in which parties compete to unravel the cases given disk images, memory dumps, and malware samples from actual compromises - they submit their reports of what they found, so you can see the sorts of tools used and findings made in this field.

Anti-Forensics is a hot topic in the comments - basically, "can't the attacker just hide their traces?"  There are ways to chip away at it - see this list of techniques - but it's far from perfect and not what I'd call reliable.  When you consider that "the 'God' of cyberespionage" went so far as to occupy the firmware of the hard drive to maintain access to a system without leaving a trace on the system itself - and still got detected - it seems clear that, in the end, it's easier to detect evidence than it is to erase it.


what would be a good way for a doctor to send xrays encrypted to another doctor? As a dentist, I often want to send medical information including digital xrays to another doctor.  What would be a good/easy way to do this encrypted?

Our organization currently requires that all such sent information be encrypted.  Their current method is an add-on program to our email, that automatically encrypts the attachment.  The problem with this though is that the recipient needs to also have this particular program installed on their computer...

I would like a way where the recipient can easily access the file without having to install new, additional software.

(to answer the question I live in America (Oregon).)
(thanks for all the great responses!)

Sending healthcare information like that is very tricky, since you have to meet the healthcare security and privacy laws in your country (HIPAA in America). You might be able to use something like PGP to encrypt the emails and this may fine legally (I'm not a lawyer though). Encryption implemented through PGP would have fairly good support in email clients, so it should work for most places you want to share data with. However, this is a very hard-to-use solution. I'd be much better to not have to email PHI like that. You still have to worry about auditing access to the data, as well as proper access control.

What you really need is software that can enabled collaboration between two healthcare providers. This would give your organization a lot more power than what you currently have. This software would then handle the secure communication between the two healthcare practices. It would also let you share this data in a much easier, standards-based way.

As a side note, I started a Healthcare Industry Stack Exchange proposal where this question would be perfect. Those interested in questions like this should consider joining.


How to prevent a click from opening another tab? On some website everything looks fine until I click on a link (the link displayed in the lower left corner is normal as far as I can see and different from the one opened in another tab).

When I click however, sometime another tab is opened (and not the one I clicked on). Before the redirect I was able to copy the link:

javascript:window.opener=null;setTimeout(function(){window.location.href='http://papcontent.info/[...]'},250)

Can I prevent this javascript snippet from beeing executed without blocking the whole scripts with NoScript? The later does, unfortunately, render the website unusable.

The link that gets opened in the other tab is not the one I clicked on. It is not even in the source code of the webpage (neither in the generated one I got with the Webdeveloper plugin, nor the saved to disk one was the string "papc" or ".info" present).

The website is not mine and I prefer not to post the link unless it is really needed.

I am not sure what details to put, so please ask questions and I'll add them.

This is called a "popunder."  They're essentially very rude pop-ups.  Some would go so far as to call them malicious.
To get around them, try this:

Chrome: Right click the link and choose "Copy link address" from the shortcut menu.
IE: Right click the link, choose Properties, and copy the link address.

Open notepad and paste your clipboard there

Notepad should now contain the URL you want.  Visually inspect just to be sure.

Cut and paste the URL from notepad into your browser's address bar.


Can I use John the Ripper to brute-force a password-protected flash drive? I have a password-protected flash drive. The input window allows unlimited password attempts, but this form is not an encrypted file.

Can I use John the Ripper to bruteforce the password?

No. John the Ripper is designed to look at a hash and compare it to common password hashes, salted or unsalted. It doesn't directly input values into a box, and it uses GPU acceleration when available to reduce processing time. Unless you can find the hash for the password on the flash drive, this tool is completely worthless for this purpose.


Users never remember their passwords or security answers. How can I get them to remember, but follow good security practices? I work at a library where I teach computer literacy classes, especially for the elderly. Among other things, we have classes where people set up e-mail or other online accounts. For many of them, this is their first exposure to passwords. About once a month, I'll have a conversation like this:

Patron: Can you show me how to do e-mail again?
Me: Sure. First, go to the e-mail provider's website. Good. Now type in your e-mail address and password.
Patron: I don't remember my password. I didn't think I would have to remember it.
Me: Your password is important. It lets the e-mail provider know that you are who you say you are and not someone else. Fortunately, we can try to reset it. Click that link there. It's asking security questions that only you would know. Looks like it's asking what your favorite book is.
Patron: I have no idea.
Me: Well, let's have you put in a couple of guesses.
Patron: None of these are working. Can we call Google and ask them to help?

I've had several patrons locked out of their accounts permanently because of this. I've tried having them write down their passwords. Not good security practice, and quite often they lose it (or worse, can't read what they wrote). They've tried to get me to remember their passwords for them, but as a library worker, it would be inappropriate for me (and that has all the problems of asking family members to keep your passwords). Yet nothing seems to help with having them remember their password.
Regarding security questions, I've instructed them to choose security questions that won't change. So don't choose "what's your favorite food?" but instead choose "where did you meet your spouse?" A few months ago, I actually had someone forget that too! They couldn't remember if they put the city, the name of the restaurant, or whatnot, and they never figured it out.
I had one patron who independently decided to put their e-mail password on a post-it note on their computer. I felt like screaming inside because that's an egregious security issue, but at the same time I was overjoyed that they didn't forget it any more. I didn't know if I should say anything about it.
So for users who chronically forget their passwords and security answers, what can I do to help them remember, yet still follow good security practices?

For an average user that is unlikely to be the subject of a targeted attack, then the main risks to consider are those posed by automated attacks and bulk leaks of account details and password hashes when various websites are inevitably compromised.

The key mitigations for these are

a) passwords of sufficient complexity (generally at least 8 characters, not a simple word and not based on public able available information about you)

b) passwords are not reused on different sites.

For most people with many accounts the above two largely rule out memorisation of anything but passwords for one or two accounts, with the rest stored somewhere.  An encrypted password manager is a good choice, but written down is equally effective for the above risks, provided they can store it somewhere where access is limited to prople they reasonably trust.

For many home users, a simple notebook with all of their passwords written down and stored as home is simple to understand and effective at mitigating the main risks they face.


"Triage an incident" I have been trying to find a definition of triage in relation to Information Security but cannot find any online. From the different examples given online (i.e. medical world), it seems related to determining the incidents priority/urgency and putting it in relation to your other issues.

Does this seem correct or is it something else?

Yes, it's not got a distinct meaning in information security - from dictionary.com:

  the determination of priorities for action

So, deal with the most critical problems first, working down the list of known issues, trying to minimise the overall problems you can face.

Usually goes something along the lines of:

Make sure no-one else can get into the system
Take an image of the system
Rebuild the system from known good
Find out exactly what went wrong in great detail


Is someone trying to hack?

Your system has already been compromised because multiple POST requests were successful and all those unauthorized files have appeared in your folder/s.

From the information provided, I would assume that the gallery on your system has holes in it that allow uploading .php files which can be used for arbitrary code execution.

What you could do to confirm this is to look for the point of entry in the logs. Look for the first POST request which added a suspicious file on your system. Furthermore, you could track down all these unwanted files and delete them afterwards but to be 100% sure that the infection is gone, you may want to completely wipe and reinstall the system.

Now, this doesn't quite fix the problem as the exploit remains in your current WP version so consider updating to the latest version.


VCS to manipulate returned trees to prevent leaks? I am wondering if there is any system that would change source code trees in subtle from version control systems in ways that are hard to discover (i.e. whitespaces at the ends of lines, perhaps even change some less variable names) to "watermark" the code so that it would be possible to find out who pulled it from the repository. Do you think that such a system would scare the developers from uploading the code online?

Edit:
To address the "that's a trust issue" argument, I'd like to point out that it's a hypothetical question and I was thinking of this as of a way of preventing a developer from leaking the source code in a huge company, where lots of developers have access to whole the tree.

Before this gets out of hand with the edits and the comments, I wanted to say this.

This is not a hypothetical situation. Almost all software companies face this problem, and it all boils down to a trust issue. This topic has been extensively discussed on other StackExchange sites, most of the answers can be summarized in:

  1- Hire people you trust.

  2- Make then sign an NDA.

  3- Give them access only to the code they need

I'll just expand on the last point to address the situation about which you're wondering. In the case of Windows, I'm 99% sure than not all Microsoft employees have access to the Windows source code. Not even the employees who work on Windows have access to all of the Windows code. Each employee should have access to the parts of code he's responsible of maintaining.

Developers on Project A don't need access to Project B's code, and so on.


How can we show our end-users that we are trusted by a bank? We are developing an website which serves end users of many organizations
(banks  , municipalities etc).

We have already setup meetings with the banks and they've agreed to work with us.

Ok so let's say that a user user1 of bank bank1 is entering bank1's website - then he sees a legit certificate of bank1 and a link for newService1 -  : "For using the new service please click here"

This way - user1 can be sure that the new service is trusted by bank1 since bank1 showed the link to user1.

Question

But what about the scenario where user1 has entered newService1's website directly and NOT via bank1 ? How can I show the user that newService1's website is trusted via bank1 ?

Sure I can create a link (in newService1's website) which says : "This service is trusted by bank1 - click here to see confirmation page in bank1's website".

Are  there any other trust mechanism which  newService1's website can implement to show user1 that newService1's is trusted by bank1 ?

NB
By trust I mean some kind of proof for user1 that bank1 has agreed to work with newService1's  .

If it is possible in your scenario, you might want to "multi-host" your service, under a subdomain of their domain.
E.g. newService1.bank1.com, and have them provide you with their own HTTPS certificate.

This creates an environment where you not only trusted, but it is THEIR service - at least from the perspective of the user, especially if you provide whitelabel branding, their logo, etc.

Note that in this case, you should isolate the bank from other tenants' service - on the backend as much as is feasible, but especially from the user's PoV. E.g. don't make the user re-select which is his bank, or any other bank-defined configuration, you need to function as if you ARE the bank's system. Or if you send out emails to users, these should be identified as the bank's newservice.

(P.S. this also can give you some great marketing tools, onboarding options, and easier to close the sale with many organizations... )


Is there any way to cryptographically hash a human thumbprint? Is there any way to cryptographically hash a human thumbprint into a form that can be consistently reproduced by thumbprint readers?

Assuming that it would be possible to create a database of thumbprint-hashes, my intent is to salt that hash with a "something you know", preventing the thumbprint database to be used for anything else other than authentication.

Question

Is it reasonable to "salt" a hash(human thumbprint) and use that for authentication?
Are there any technical requirements (resolution, datapoints per finger, etc) that would ensure accuracy across devices?

As @Xander points out, a very similar question has been asked yesterday. Indeed:

If you can derive a key from a fingerprint, then you can hash that key and get a hash value.
If you can hash a fingerprint, you can use the hash value as a key.

So they really are the same question. And the answer is: people are working on it, it does not work well yet, but might improve over years.

I would like, though, to point out something important: a "something you know" has any value for authentication only because it is also "something that the attacker does not know". It is the secrecy which confers the power.

A fingerprint, like other biometric measures, does not really work on secrecy (although many systems try to use it that way). The important characteristic of a fingerprint is that it is attached to a human: when a human being uses his own finger on a reader, he cannot help but using his own fingerprint. Indeed, that's where the innovation is in modern fingerprint readers: in the systems which try to ensure that what they are detecting is really a human finger still attached to its nominal owner's body.

Secrecy is not a big part of fingerprints for security. Your fingerprints are not secret: you leave them everywhere, on your car, on every door handle that you go through, on the elevator buttons, on every glass that you use in a bar... If a fingerprint can be turned into a key (or hash value, regardless of how you want to see it), then that key can be rebuilt offline, from any copy of one of these prints. There is very little secret here.

To sum up: even if you could reliably turn a fingerprint into a key, it would not be a good idea to use it as a secret key. It would be useful as an indexing key, though: not for security, but for performance.


Is This DIY Password Authentication Scheme Acceptable? This is mostly a thought experiment for client/server communication, and I want to know the flaws.

When a user account is created (with U as the username and P as the password,) I generate a random salt (S) and store these values in the database (on the server-side): U, S and H which is computed as H = hash(U+S+P).

When authenticating a user:

The client first "attempts an authentication" by sending U to the server.
The sever creates a challenge code (R) for that user and stores it in the database, along with the time this challenge would expire (T) and sends R and S back to the client.
The client calculates its own version of H (by hashing U and S and P together; it has U and P, and received S from server.)
The client then computes a new value G as G = hash(H+R) and sends this G back to the server (actual "authentication request".)
The server hashes its own H together with R to reconstruct G and authenticates the user iff its G matches the value received from client and T has not passed yet.
Whether authentication succeeds or fails, R is removed from the server database.

The flaws I'm already aware of are these:

When creating an account, the password is transmitted in plaintext. This can be mitigated using a dedicated account-creation service that employs SSL for creating accounts.
Attempting an authentication will result in some resources being allocated on the server. This can be mitigated by allowing only one (or a fixed number) of challenge codes per user.
Trying to discover valid usernames and salts by generating many authentication attempts; which the server can foil by sending a random salt and challenge code even when the user does not exist.

Here are my specific questions:

What am I missing? Where is the disaster waiting to happen?!
What can I do to make this more secure/better? Other than using SSL and just sending plaintext passwords (plaintext only from the perspective of my application.)
I'm thinking of SHA-256 for all hashes. Are there any flaws in the SHA-2 family? Is hashing the values once enough for generating H and G?
For generating H and G, are other permutations of values better? e.g. P+U+S, R+H, etc.
What conveniences am I denying my users? (Apart from their authentications now needing two round trips to the server.)

UPDATE: Ultimately, I want to do this:

After a successful authentication, the server generates a session key K as: K = hash(H+F) where F is a random string. F is sent to the user and K is retained in the database. The client reconstructs K using the received F and encrypts all communications with the server henceforth with a symmetric cipher (e.g. AES) with K as key.

Your main problem can be summed up as: where's the SSL ?

Any eavesdropper, observing the exchanges, will obtain enough information to run an offline dictionary attack: the attacker will be able to "try passwords" by recomputing the relevant hash values and see if they match that which was observed. This is "offline" because the attacker can do all of this on his own computers, without interacting with the client or the server. The attacker can do all of this at the speed of his own machines, and, thanks to the fact that usual hash functions map very well to what modern CPU and GPU can do, he will be able to try billions of passwords per second. Not many passwords will last long under these conditions.

You could try to do some prior Diffie-Hellman to get a shared encryption key, and encrypt everything with that, but you have just moved the problem to that of making a Man-in-the-Middle attack: you think you talk to the server, but you are really talking to the attacker, with whom you do that DH key exchange. The attacker is then back to the previous situation, and can observe the hashes that allow him to run an offline dictionary attack.

The normal solution is to first setup a secure tunnel to the server, that at least guarantees to the client that he is talking to the intended server and nobody else. This is called SSL (or TLS, which is its "standard" name). Once you have such a tunnel, you can use a much simpler "show the password" authentication method, and the tunnel will also ensure that all subsequent data exchanges will be linked with that authentication (i.e. attackers won't be able to hijack the socket after the authentication steps).

SSL assumes that the client has a way to verify the server's identity -- that's the point of the server certificate. If you want to do without that certificate, and achieve password-based mutual authentication of the client and the server, but without revealing anything that would allow attackers to run offline dictionary attacks (even active attackers that try to impersonate the client or the server), then you need one of these nifty password-authenticated key exchange algorithms. There again, use SSL, with SRP cipher suites. The only known protocols that succeed at such certificate-less password-based authentication without offering offline dictionary attacks use some maths; you won't achieve that by simply using hash functions.

Regardless of the authentication protocol, you still need a secure password hashing function for whatever you store on the server side, to avoid transforming a read-only partial intrusion (e.g. through some SQL injection) into a password-breaking fiesta.

And, of course, in cryptography, "do-it-yourself" is the fastest road to Hell.


Why do some passwords not allow certain types of characters? Is there any programing related reason why some password cannot have certain characters? If the idea in storing a password is to store it's hash, since a hashing function can take any input (ok at least I guess any reasonable hashing function can take punctuation) why would a program not allow some passwords? Does this mean a hashing function is not used, then what is?

An example is LAN Manager

  Passwords are not case sensitive. All passwords are converted into
  uppercase before generating the hash value.

When I worked for IBM we had to fill out the hours we worked by entering them into mainframe running z/OS. The password for this had to be a very particular format, something like 3 digits followed by 3 letters. I asked if the passwords were stored in plain text and the answer was "no but the system is ancient".

Any restriction of any shape or form on the passwords will decrease their entropy, making them weaker. Fewer limitations = more possible combinations. There's no technical reason why passwords should be limited in anyway*. It's not a programming related issue, it's a chimpanzee-related issue.

That is especially the case if you're properly and securely hashing your passwords.

* In some very old and legacy systems, there might be some technical limitations related to encoding, acceptable characters by the operating system itself, and so on. Of course, that doesn't exist anymore, and there's no reason for us to imitate the behaviour of those old systems.


Protect an application that uses internet from packet sniffing I developed a stand alone application such a way that, application use a remote service (using SOAP/REST) which available WWW. I am using HTTPS though out the application calls. It was perfectly working fine. Recently I found that some users using a web proxy like Fiddler to sniff the application traffic and monitoring application WSDLs, request and responses. I introduced JWT(JSON Web Token) to prevent man in the middle attack, but again, JWT messages can be captured and decoded to see original requests and responses.

I found another way to protect application request and response is to encrypt individual packets before send using any symmetric key algorithms such as AES or zip up with AES encryption. But this will affect performance of the application badly.

Is there any other way to address this issue without affect much on application performance?

If everything is made through HTTPS, all your application have to do is ensure the certificate is correct and valid.

Man in the middle attack can only decrypt HTTPS traffic by ruining the original certificate and issuing a [generally] self-signed one to the local peer communication.


Can an attacker who has wiretap access to my phone line intercept internet traffic? At what points on a (wired) phone connection can a wiretap occur?

At any of these points, if an attacker gains access, is it possible to intercept/read/modify internet traffic that uses the line?

Data traveling over wires is vulnerable.

Physical access to a network’s signal provides an attacker with the capability of reading any cleartext (unencrypted) traffic traveling over that network. It doesn’t matter if it’s a phone line, Ethernet, or WiFi signal.

Radio signals are an obvious target for eavesdropping, because the signal is literally broadcast in all directions. With WiFi signals being so easy for anyone nearby to intercept, the WiFi security standards have been designed to encrypt all the data riding over the airwaves, making interception at that specific link in the network harder.

However, the same philosophy has never been applied to hard wired connections. Wired connections are not encrypted by default. Tapping a phone wire is not something a typical person imagines could be done while sitting at a table in a coffee shop, or walking down a hallway. Those same people tend to think those wires are private.

But technology has advanced for everyone. You can buy a LAN tap for a few dollars, and hard wire your own tap. You can buy a Packet Squirrel for a hundred bucks and plug it in to an Ethernet port on the back of a WiFi access point, and you’ll have cellular access to whatever data travels over that network - without breaking the WiFi encryption.

Instead of trusting the security of the wires, you should secure your communications. Make sure you are connected using HTTPS (the little padlock appears in your browser. ) Don’t fall for phishing emails. Take security precautions assuming that all your data, both wired and wireless, might be intercepted.

Edit to address comment:

HTTPS uses TLS to encrypt the data between the client and server regardless of the network hardware between them. With TLS it doesn’t matter if they’re apps on mobile phones or browsers on hard-wired PCs, the data is secured the exact same way. Your browser or app is one end of the secure connection, and the web server is the other end. Person-in-the-middle attacks on TLS ultimately require compromise of one endpoint or the other.

No one can guarantee the absolute security of HTTPS, because there have obviously been many successful attacks, including spoofed sites with fake URLs and legit certificates; injection of a compromised trusted root certificate in the client and a PITM proxy; weaknesses in the SSL protocol; forged MD5 certificates; compromised certificate authorities; keylogger malware on the client; malware on the server; etc.  But as of late 2018, TLS 1.2 is as close to resistant against network wiretap-type attacks as it gets.


How to protect API Key in Android application I was working on one Android App which was communicating with RESTFull server. We made an API Key which was inserted in header of GET and POST requests. This API Key was stored in Strings. App is no longer used and also server is down.

I found app.apk file and was curious how it is secure, so I decompiled it's source and found API Key there like this. We didn't use ProGuard because we didn't have time.

The queston is how to store API Keys in android applications because this way I can also obtain Google Maps API Key.

So, you're asking if you can store the API Key in the App, but also protect it from being stolen? This is not possible.

There is a possible solution to make theft more difficult. Use OTP XOR encryption so that the API Key is split into two parts that must be combined.

The first part is stored in your application.

The second part is downloaded from your server equipment and then stored in the App-Private data, preferably in such a way that does not make its purpose obvious. Alternatively, you could 'not store' the second part, (keep it in Application Memory or Intent Extras only) but then you'd have to download it from the server every time the app is launched.

Then you can use Progard to make the overall application more difficult to understand.

Of course these only make theft more difficult, and do not actually secure the Key from theft.

If you really need to secure the key, then you'll have to route all requests to the Google Maps API through a Proxy server which you control. That Proxy server can add the API Key to each request as needed.


Using htmlentities() in a BBCode-supporting textarea to stop XSS I want to have a text area to post stuff to the database with BBCode. So, I downloaded a JavaScript code (to write in the specific BBCode when the image is clicked) but it didn't transform the text.

There are images of letters above the text area like B, I and U. When I click one of them, maybe B, the JavaScript inserts [b][/b]
to the text area. But when I submit the text with some other text in the bold BBcode, it doesn't make the text bold.

So, I thought this would work:

str_replace('[', '<', $_POST['text']);
str_replace(']', '>', $_POST['text']);

It worked but I can't add htmlentities() now which I've been using to prevent XSS. So, what other options do I have to stop XSS?

Parsing BBCode in a safe way that does not open the doors to XSS hell is a tricky task, and there have been many failed attempts. As you yourself note, the way you currently do it is vulnerable to XSS - all you need to do is post [script src="evil.js"]. Just using htmlentities() will not solve this for you, it is much more complex. This blog illustrates the problem neatly.

So I would not recommend you to try to implement your own BBCode interpreter. Instead I would look at existing libraries, either in PHP or client side in JavaScript and evaluate their security record. Some places to start:

The PHP BBCode extention
Some different JavaScript options at NPM

To add an extra layer of security you can run the generated HTML through a HTML sanitizer designed to "sandbox" HTML and keep any unwanted tags or attributes out (like script or onerror) in case the BBCode library should fail you. Some examples:

HTML Purifier (for PHP)
sanitize-html (for JavaScript)

Do note that I have not evaluated the security of these libraries. Perhaps there are better alternatives - these are just provided here as examples. Whatever library you pick, you will need to look at its track record and decide for yourself if you trust it or not. And as usual, make sure to keep the libraries updated.

As SilverlightFox says in comments, as third layer of defense (for browsers that support it) you can set a content security policy that disallows inline scripts.


How is tunnelling SSH through Proxytunnel/HTTPS different from doing it through SSL with Stunnel? In an answer to What is the difference between SSL, TLS, and HTTPS, it's said that HTTPS is HTTP over SSL/TLS.  That is, an SSL/TLS connection is established first, and then normal HTTP data is exchanged over the SSL/TLS connection.

So, if I use stunnel to create an SSL tunnel, and then pass HTTP traffic through it, would it be the same as using HTTPS normally?

Then, if a proxy/firewall sees only an SSL/TLS connection with encrypted traffic, how could it know the traffic isn't HTTP?

In theory, I think that if the proxy/firewall can't notice the difference, one should be able to tunnel SSH traffic through an SSL/TLS connection (created with stunnel) instead of HTTP.  However, in practice, I have seen this not work - the proxy/firewall appears able to detect that it is not HTTPS traffic.

I think this is why Proxytunnel is used, but I don't understand what Proxytunnel does differently to avoid detection.  Does it just create fake HTTP headers?

How is the firewall able to detect the difference between HTTP and SSH, when they are both tunneled through SSL/TLS?

TL;DR - I think your problem is not related to SSL at all, but you are trying to use a proxy server without the proxy headers.

  So, if I use stunnel to create an SSL tunnel, and then pass HTTP traffic through it, would it be the same as using HTTPS normally?

Yes. We use http over stunnel at work to talk to an https-server. That's a workaround for a bug in the Java https client that is not able to talk to an ISS https-server in some situations.

  Then, if a proxy/firewall sees only an SSL/TLS connection with encrypted traffic, how could it know the traffic isn't HTTP?

A normal proxy/firewall is not able to tell what is inside.

There are decrypting https-proxies. In order for them to work, they need to trick the client into accepting their own public key instead of the public key of the real server. In https the public key is part of a certificate which contains information about the server name. The certificates are usually signed by CAs, which the browsers know as trustworthy.

The proxy server needs to fake the server certificate in order to get the client to use his own public key. A normal client will display a warning about the invalid certificate. But the proxy can sign the faked certificates with its own CA. And the administrator can install the CA as trusted on the clients.

  In theory, I think that if the proxy/firewall can't notice the difference, one should be able to tunnel SSH traffic through an SSL/TLS connection (created with stunnel) instead of HTTP.

The common way to tunnel SSH out even works without the SSL layer on non decrypting https-proxies.

  However, in practice, I have seen this not work - the proxy/firewall appears able to detect that it is not HTTPS traffic.

Either you are doing something wrong, or your are behind a decrypting https as explained above.

  I think this is why Proxytunnel is used, but I don't understand what Proxytunnel does differently to avoid detection.  Does it just create fake HTTP headers?

You have to distinguish between a firewall and a proxy here: If there is just a network firewall you can connect to the target ip-address on port 443 normally. But if there is a proxy, you need to connect to the ip-address and port of the proxy and then tell it to connect to the target using the http protocol. The command is: CONNECT target:port HTTP/1.1 <cr><lf>

In most cases https-proxy-servers allow connecting to any ip-address but only to port 443. After sending the connect-string, you get a http response header. On a normal https proxy any further information, is forwarded as is into any direction. So you can speak any protocol you want. Using ssh natively from here on works.

In theory a firewall or dumb proxy may prevent this native tunneling by detecting non SSL-traffic. But this is very uncommon. Only a https decrypting proxy will be able prevent this kind of tunnel effectively.