Is it possible to run a MITM attack on WIFI hotspot (completely opened hotspot)

Example: can an attacker sniff traffic and credentials from a bar?

Sure! If you want, buy yourself a WiFi Pineapple and you can do the attack yourself.


Traditional 2FA versus PIN + OTP I've just migrated to a new email company and they offer a type of 2FA I've never came across before.

Traditionally in 2FA you enter username and password then are presented with a screen asking for the generated code token. Sometimes you simply append the token to the password for times that a second page isn’t possibly, VPNs for example often use that.

The new company I'm dealing with has you create a 4 digit PIN and when you enable 2FA you no longer sign-in with your password but use PIN + token entered into the password field on the login form. The account still has a password for IMAP, SMTP, POP3 etc access.

This seems much less secure to me but I'm not sure if I'm right. My thinking is that a suitably complex password (let's say 32 characters of letters, numbers, and symbols) followed by the token which changes every 30 seconds is going to take infinitely longer to crack than a 4 digit numerical PIN combined with the same token.

In this case would it be more secure to use a suitably complex password without 2FA enabled that you change every couple of weeks than the 2FA implementation with PIN + token?

Note: The company itself both refers to this system as 2FA and OTP interchangeably, but I'm not entirely sure what the correct terminology should be.

Instead of:

alphanumeric password of reasonable length (36 possible characters over, let's say, a max length of 8 characters for a typical user) [does not account for special characters, but I already suspect there are other issues]
token

The system uses:

4 digit password (10 possible characters over a length of 4)
token

This is demonstrably a much weaker system, even if I design a very weak password system (outlined above). Plus, the UX is odd, but that's another factor.

But, is it too weak?

The fact that the token changes every 30s mitigates a lot of problems. Having a password means that if someone gets ahold of the token generator, the account still has some protections. But is 4 digits enough of a protection?

Two risks to consider:

Someone bruteforcing the pin+token pair

This is entirely up to how fast the system allows attempts within a 30s window. So, maybe it is secure enough. But do we really want to rely on a system throttle as a security measure? Throttles are a nice backup measure, not a primary mitigation.

Someone bruteforcing the pin if they have the token generator

Mathematically, to go through all the combinations would take 10,000 guesses (5000 on average to find success), if entered by hand, and if we assume perfectly random pins. That's a lot of ifs. Again, it is dependent on how many attempts the system will allow. Also, pins are notoriously easy to guess.

Compare this to a 'complex password' (however you want to define that) that you change frequently. Here's the thing: without the changing token, you change the time to bruteforce from 30s to 2 weeks (in your scenario). Now, the relevant factor is the complexity (or entropy) of your password and your system to reliably change it frequently. Again, a lot of dependencies.

As you can see, it is difficult to compare the factors that you laid out. A lot of 'ifs'. For the factors that I have control over and the risks that I am worried about, I might choose the pin+token (assuming that the 2FA is implemented properly (whoops, another 'if')).

But really, I'd choose another service that can implement 2FA properly.


Oracle Transparent Data Encryption Currently we are using Vormetric for Transparent Data Encryption (TDE) in the Oracle Standard product to satisfy PCI-DSS 2.0 requirements. Does anyone have experience with other third party solutions for TDE? Using Oracle Enterprise and the Advanced Security Option (ASO) has been cost prohibitive to this point. We've gotten mediocre support from Vormetric and are evaluating alternate solutions.

I'm sure you are aware that Oracle does provide a TDE solution.

http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html

The only time I seen this solution being cost effective if your company was large enough to have a global contract with Oracle.


What's the algorithm to generate a modulus and a base for a Diffie-Hellman key exchange app? I have a school project in which I have to write a java console application that can be used for key exchange between two people. All is fine and well, but finding good base and modulus seems to be a difficult task, especially for someone with not much mathematical background, such as myself.

I know that the two numbers have to be prime but I don't seem to be able to find any algorithm for automatically generating them. Apparently, Java has a class for it (DHParameterSpec), but I'm supposed to implement this on my own. I've read other threads on the topic, but I've found none that I can understand well.

Thanks in advance for your answers.

The easiest method to generate the DH modulus and base (collectively called the "DH parameters") is to use values which have already been generated. This does not imply security issues -- several people can share the same DH parameters without trusting each other.

Technically, you need three values: the modulus p, the base g, and the sub-group order q. Ideally, q should be a prime integer, and gq = 1 mod p.

There are nice pre-generated values in RFC 3526 and RFC 5114.

If you want to make your own, then the basic algorithm is "try random values until you hit a prime", but there are details. You have basically two choices:

Generate random q values and compute p = 2q+1; do that until both q and p are prime. When you have found a q and p with these characteristics, then you can use g = 4 as base; it is guaranteed that g will have order exactly q.
Generate random q values of the "right size" for a sub-group order (say, 256 bits) until you find a prime q. Then generate random values r and compute p = qr+1 for each r; do that until you find a prime p. At that point, generate a random value h and compute g = hr mod p. That value g will have order q (it is theoretically possible but in practice highly improbable that you get g = 1; in that case, generate a new random h).

The first method allows the use of a very small g, which gives a slight performance advantage when using Diffie-Hellman (not a big advantage in practice, something like a +15% speed at most when proper optimizations have been applied). However, generating the modulus p with that method is quite expensive, because you have to try about a few millions of q values until you find one such that both p and q are prime.

With the second method, parameter generation is a lot faster, since it goes in two stages: first finding a prime q (a few hundred tries), then a prime p (a few thousand tries). It also gives you a relatively small sub-group order, which can be nice too. However, you end up with a "huge" base g. This method is really what is done in DSS, as specified in FIPS 186-4, so if you want a formal specification with all the details laid out, go read appendix A of that standard ("Generation and Validation of FFC Domain Parameters").

In any case, you will need computations on big integers, including modular exponentiations and primality tests. Java provides both in java.math.BigInteger.


RSA fingerprint automatic change or have I been hacked? today I tried to connect to my Digital Ocean VPS through Putty(kitty) as usual, but I got the message that the server's cached fingerprint had changed, and that it could be a security compromise.

I accepted the new key because I needed to get access at the moment, but now I'm a bit curious about it.

Could the key have been automatically updated? (I didn't change it manually and root is disabled). What can I do to check if it was a potential security breach?

I'm not sure if I should post this here or on linux community, but any help would be greatly appreciated.

The first thing I will say is ouch.  The typical reasons for a finger print change are the ssh server key was re-generated (by someone), the sshd reinstalled (not just updated from yum or apt-get), your local ssh client reinstalled or --- the real reason for the check --- there is a man-in-the-middle.

In the key update scenarios, either you did it or someone else did it.  If it wasn't you, then you are likely compromised.

In the MITM scenario, everything you typed was captured and is now replayable by an adversary.  In which case you are likely compromised.  Nothing is hidden from the MITM.

So, before you assume you are compromised, please check to make sure Dig O does not manage your service for you and does not make these changes on your behalf.  Also, if you updated your local ssh client then they key could have been stomped on.  Look for logical reasons not to expect the worst --- but you are very very correct to be paranoid.  [personally I always expect the worst.  I have worked many many dozens of very significant intrusions.]

In the worst case you merely have to scratch the OS and restore your data (not executable files, libraries, passwords or ssh_keys from a potentially corrupt backup, but just your data.  If you restore services you have a race condition ... update the authentication passwords instantly.

All this assumes that any intrusion doesn't start with your local client and have propogated to the remote server -- :).

In general you should understand where that message came from and if it wasn't you -- time to get to work.


Difference between local and central anti-spam I'm attending a web security course whose slides, concerning techniques for protecting ourselves from spam, sometimes report the expressions "local anti-spam" (or "personal anti-spam") and "central anti-spam".

I suppose the "central anti-spam" is the e-mail provider's one, but I cannot figure out what can be a local (or personal) anti-spam and which can be the differences about them.

I tried to google such expressions but I didn't find anything.

Many mail programs like for example Thunderbird have a built-in spam filter. The main difference from this to most central spam filters is that it gets trained by the user and thus is adjusted to what the users typically receives as spam and ham and what the users considers spam in the first place - e.g. some like news letters, others hate these.


HTTP + HTTPS + One Time Pad/stream cipher I'm designing a web application where users will exchange short messages with the server very frequently (for instance, a few characters every second). I want the whole communication to be confidential, but the (perceived) performance must be acceptable. I had this idea of putting HTTP and HTTPS to work together using the following scheme:

The browser will request two (fairly large) keys from the server via HTTPS, then store them in-memory (in principle, I'm thinking in one-time-pad keys, i.e. random data). Then, the contents from each message will be XOR'ed with the first key (without any reuse, of course) and sent via HTTP. The server will send the response in the same fashion, using the other key. When one or both keys are about to be used up, another one will be requested, and so on.

The rationale behind this is that both the XOR and the HTTP request are cheap for small messages, so the perceived performance will be good. The HTTPS calls, more expensive, will not be time-critical and will benefit from the larger scale of the exchanged keys. Another stream cipher might be used instead of one-time-pads, and in the future (when properly supported everywhere) WebSockets could be used instead of HTTP requests.

Has this kind of thing been used before? Would this properly secure the communication, or is this a stupid idea, for any reason? I couldn't see any shortcomming, but I'd like to hear the opinion of more experienced people before spending too much time on this.

You are talking about encryption only; you are forgetting about integrity, an often fatal mistake. Encryption protects you only against passive attackers, who can spy on everything everybody says, but can alter communications in no way. That's not a very realistic model. You need verified (i.e. keyed) integrity, and for that you want a Message Authentication Code. Or one of those nifty Authenticated Encryption schemes.

Now, a protocol which begins with a potentially expensive initialization step, resulting in a shared secret, which is then used to encrypt data an protect it with verified integrity... that's not easy to build without making any mistake. Fortunately, one such protocol already exists, with all the hard bits done the right way, and implementations already available. It is called SSL.

As @Rook says, SSL is very lightweight once the initial handshake has been done. A typical HTTPS client (say, a Web browser) will first open a SSL connection, and then keep it open for sending requests. An open SSL connection implies a very slight overhead compared with raw unprotected data: in practice, about 30 extra bytes per record (it depends on the cipher suite), each record able to hold up to 16384 bytes of data, so we are talking about less than 0.2% of size increase, and you would get that with any other protocol which ensures confidentiality and integrity anyway. On the other hand, your handmade scheme doubles the network consumption (the one-time-pad is not exactly free to send).

Moreover, even if the SSL connection gets somehow closed (e.g. because the server does not wish to keep any connection open for more than 15 seconds of inactivity), a new one can be reopened with an abbreviated handshake which reuses bits of the previous handshake; in particular, it requires less messages (so reduced latency), it is symmetric-crypto only (so light on CPU), and it involves no certificate whatsoever, so it is simple and sane.


Working out how to decrypt encrypted string when knowing the plain text I have access to a system which I have been asked to create a data export routine for. However, the address details are encrypted and the original sourcecode/password are lost.

However, I am able to view through the application the decrypted text and via the database view the encrypted text. How can I work out the method of encryption/decryption and find out the password used?

examples of encrypted and plain text:

0"FCDT$&G => CF40 2BA
0"FCDW"#G => CF40 1DD
0"FCDFFGG => CF40

I believe the decrypted strings contain space padding but cannot be sure.

The generic term for "Working out how to decrypt encrypted string when knowing the plain text" is "known plaintext attack," if you'd like to research the topic more.

Luckily for you, these examples are not exactly encrypted. They're too short for block encryption; and a good stream cipher wouldn't start with the same characters each time.  After a bit of examination, it looks like they're xor'ed with a static string which starts with "sdrsdffg"

A bitwise xor with a static string is a cheap and common way to obfuscate a plaintext; but as you can see, it's not the most secure thing in the world.

There's algorithmic ways to figure out the rest of the static string if you have longer ciphertext samples.


TLS handshake random bytes reused What would happen if the random bytes provided by the client and the server in the first two messages would be reused by one peer/by both peers?

I think it would highly reduce the provided security, like for example if you use a nonce multiple times, but i am not quite sure.

Does using the same random bytes multiple times lead to a less secure TLS connection. If so, why and what would happen?

If the server uses the same server_random in the 'server hello' message, then this could enable an attacker to launch a replay attack.  See SSL replay attack when client/server random is missing for more info.


Sniff email content inside network I use Cain and Abbel and I want to see the email content.
If you help me becouse I don`t know to see the content.
I see the email in the section password but I need to see the email content .
I can simply with Wireshark?

Thank for what you said,I understood and I made ARP Poisoning.So I see at Passwords->HTTP two URLs:www.yahoo.com and one hsrd.yahoo.com after this things what I need to do to see the email content like : Hello..what I wrote in email.

I use now Cain and Abel.

Thanks.

Yes, Wireshark will do the job.

If you want to sniff your own mails just start it on the corresponding interface.

If you want to sniff all mails in the network you have to somehow put yourself in a man in the middle position. You could use Cain for that if you have it installed anyway and it supports ARP poisoning, which is one possible method.

After sniffing for a while you can check "Statistics -> Conversations -> TCP" for the TCP sessions. In there you can select one and click on "Follow Stream" to see everything.

This will only work for unencrypted mails transfered over unencrypted protocols of course.


Certificate Authority generates private key for Extended Validation code signing certificate? My company upgraded to an Extended Validation code signing security certificate, which was delivered via mail on a physical USB key, called a "token."  The token contains a private key and the digital certificate, both generated by the Certificate Authority (CA).  I was surprised that the CA created the private key.  It is my understanding that private keys should never be shared with a third party, including a CA.  I'm used to the Certificate Signing Request (CSR) process, where a company keeps its private key private and only shares its public key.
My question: What security concerns are there with a private key being generated and initially owned by (in possession of) a Certificate Authority?  Is this standard practice for EV certificates delivered on a physical token?  We are told that the private key only exists on the token and there are no other copies.
Perhaps I'm missing the point.  Maybe it's more about establishing trust with a CA, and therefore we should also trust that the private key was handled correctly and that we have the only copy (E.g., why do business with them if we don't trust them).  At the same time, alerts go off because a third party had our private key.  I realize that it might not be practical to create a token unless the private key is present, so maybe it's inevitable that the CA possesses it at some point.

It is common for code signing certificates to be hardware backed, since in the past there was lots of misuse by stolen code signing certificates. Hardware backing a certificate means that the actual hardware needs to be present when signing. The signing itself happens on the hardware itself, i.e. the private key never leaves the hardware. The hardware is designed so that it should be kind of impossible to extract the private key from the hardware.
For this use case the private key usually is created also directly on the hardware, i.e. not created outside and then stored on the hardware. This means that the CA does not have access to the private key either. But yes, one needs to trust the CA to actually implement it this way.


Odd user registered and strange behavior. Is it sinister? I am running a number of web sites. They are all Drupal based, if that is relevant. Recently I have noticed something odd.  All my sites have a user registered with the name "zctonglin".  I presume that user is a spammer  because of some initial behavior typical of a spammer. Based on that, this user has been blocked on all my sites for a few weeks. The odd thing is that multiple times every day I still get some attempts to log in as "zctonglin". These attempts originate from a variety of different ip's,  making them unlikely to originate from a single computer or network.  They could originate from controlled machines, of course.

The email addresses (required for a two-step registration on my sites) used for registration are obviously disposable ones.

Doing a bit of research on the net. I noticed a lot of spam by zctonglin on many, many, sites.  Google returns over 300,000 hits for zctonglin, but as most of these are users on a variety of web sites, it is not a very useful search, although within those results there may be something more relevant to my investigation. I have not found it yet.  "zctonglin" being an unusual name I think it is more than mere coincidence. I am wondering if there is an automated exploit software that has zctonglin set as a default user.  That would explain things to my satisfaction. If not, then the very large number of zctonglin traces on the internet make me wonder whether there is something more sinister at play here.

I could setup a dummy site, wait for zctonglin to register (which I guess s/he will, specially if I link from an existing site), or allow him/her to re register on a current target site (I am very reluctant to do this for the obvious security implication) and see what exactly s/he is doing but I doubt I would learn more that the Google search on zctonglin gives me.  So, II would rather get an explanation from a security ace!  :)

Has anyone got any clue about this phenomenon, anything to add, or a suggestion about what to do next? None of the sites I manage have been compromised in anyway yet,  afaik. At least I cannot find any evidence of it, but I am not happy to let things rest when I don't understand them.

Thanks for any help

Edit for additional info:

One of the site is a site has very little traffic except for spammers (which get moderated out and are not an issue except for the bandwidth and CPU).  It is very new (10 weeks live) and has very little substantial content.  It literally only gets none, one or two legit visits a day, yet zctonglin attempts his/her login about 10 times per day on that site and has done so for about 6 weeks (from very different ip's each time).

So, if it is a single individual, he probably uses compromised machines all over the place.

My concern would be more a scenario where the user zctonglin acts as a backdoor for many hackers.

I guess, if I really want to get to the bottom of this, I will have to setup a honeypot which is something I wanted to avoid on account of the work involved.

There are are two possible explanations that are very likely:

It might just be a very simple botnet client that uses a hardcoded string as username. There is a number of press reports saying that botnets owner offer there services to third parties. So while creating a botnet requires a lot of knowledge, the person using the botnet might not have much experience.
Someone might try to discredit a person with that name.

PS: Please do not post personal details about people using that username as nickname as it is quite unlikely, that they are responsible.


Can a blog owner trace my IP address when I use incognito mode? I access a blog hosted by blogspot using Incognito mode. I comment on one of the posts, by signing into my Gmail account (as the blogger does not allow Anonymous comments). If I comment by visiting the blog on an Incognito window, will the blog owner have access to my IP address and location?

If yes, is there a way to guard my IP and location from being visible to the blog owner?

If I comment by visiting the blog on an Incognito window, will the blog owner have access to my IP address and location?

Yes. Incognito mode just stops your browser from keeping history.

  If yes, is there a way to guard my IP and location from being visible to the blog owner?

You can use a VPN or anonymyzing proxy.


Access token vs. UserID + access token My goal is to associate (authenticate) hardware devices to users in the database. The access token is generated via webinterface. It is then entered into the hardware device by the user, and the device uses it to authenticate to the webserver. The token is 20 digits random hexadecimal characters and can be revoked. The maximum number of devices is estimated to be 1 million.

Is there any reason, why the user should also enter a userID to the device? Or is the access token sufficient?

Thanks

Without an userID attacking your system can be done a million times faster than with userID. That seems like reason enough to me.

With an userID an attacker can only attack one token at a time. Without userID he can with one try attack all 1 million at once.


Can I modify a ciphertext created in AES with OFB mode? Suppose a service uses AES to encrypt Cookies, of the form

user=username+padding,tmstmp=timestamp

where tmstmp is the expiration time and +padding is a series of zeroes to make the total length be a multiple of 16 bytes.

If they create their admin cookie by just using admin as the username, like

user=admin000000,tmstmp=timestamp

Is their any conceivable way to take an encrypted cookie for a normal cookie, i.e.

AES(user=joesixpack0000,tmstmp=timestamp)

and turn it into an admin cookie, without knowing the Key or IV used in the encryption?

What you are discussing is called a known-plaintext attack:

  The known-plaintext attack (KPA) is an attack model for cryptanalysis
  where the attacker has access to both the plaintext (called a crib),
  and its encrypted version (ciphertext). These can be used to reveal
  further secret information such as secret keys and code books.

But

  Modern ciphers such as Advanced Encryption Standard (AES) are not currently
  known to be susceptible to known-plaintext attacks.

While you may find this inconvenient, it is important for the security of our digital world. Consider the fact that HTTP messages frequently start with predictable sequences of text (HTTP reference). So the start of an HTTPS message is somewhat predictable. This is true for many other types of encrypted data. If someone could guess the plaintext and then be able to decrypt or modify the message, the situation would be rather dire.


Should text files or image files be virus scanned during upload? I have created an online web app for my company. It's being tested for security files. The tester loaded the EICAR text file. The virus scanner on the server caught and removed the file.

I have only allowed text, gif, jpg and pdf files for upload. How likely can a text file, image file have a virus? I know things changed a lot lately. We are on Windows 7. My question is, is there even a need to run a virus scanner for such file types? Thanks.

Long, long time ago there have been a rumor that there is a virus able to infect gifs. All the wise people laughed at the idea of data executing code. But then, buffer overrun attacks have been discovered, and a bug in Internet Explorer that allowed buffer overrun in gifs, essentially executing malicious code.

The moral of this story is a double-ended one. First: there is always a possibility that data could be used as "viruslike" attack vector. Second: There was absolutely no possibility any virus-scanner could have detected it before attack was discovered.

I can only recommend scanning data files if there is a known attack which could compromise users during regular usage (and your AV detects it). Scaning every .txt for being renamed .exe seems bit overkill. More importantly, you should be ready to re-scan old, EXISTING files, in case a new attack is discovered. Scanning existing files is easy, the problem is what to do next - witholding access to the file, notifying it's owner, etc - it's a lot of work to design and implement such error-handling.

As raz said, pdfs are different beasts: they are already known to contain code and have to be scanned both on upload, and in storage in regular intervals.


Can prism know even data outside the US Data centers? I would like to know whether the US Prism can know even the data outside of the US Data centers.

For example, If I have my own servers and all the data in Indian servers but I have been using some services like web application acceleration, security, domain name registration etc from US companies, then is there a chance of US Prism knowing my data?

Anyone who really knows the answer to this question is either prohibited from telling you or is a political refugee in Russia.  I think it's pretty good bet that any data that passes through any one of the "Five Eyes" nations (GBR, USA, CAN, AUS, and NZL) could be captured.  And, of course, other governments could be doing the same sort of thing.


Will PGP signed email be blocked in China? I generally sign all of my outgoing email with PGP. I don't usually encrypt it because most people I send mail to don't have a public key. Anyway, if I send an unencrypted message with a PGP signature to someone in China, will it get blocked or get them into trouble with the government?

I don't think it would -- at least not any regular person who isn't already under a watchful eye of law enforcement. China doesn't block encrypted communication, it just makes it inconvenient for people to use (e.g. you can use https when accessing non-Chinese sites while in China, it's just throttled to all heck, in the hopes to force you to use cleartext protocols). China's mass-filtering program is not really aimed at individual users, as much as it attempts to limit access to "undesirable resources" (pornography, anti-Chinese materials, etc). I've sent PGP-signed email to people in China on a routine basis (we host a few servers in Beijing, so I communicate with support staff all the time), and at no point this was any cause of problem.


Vehicle remote key security How secure are car remote keys? When you lock or unlock your car, can someone spoof or make another remote key?

How do car remote keys work? Do they use some kind of private/public keys, encryption?

Are aftermarket alarm remote keys less secure than the manufacturer remote keys? I am mostly interested to find out if it is possible for someone to sit in a car park and listen for remote key signals and then use them?

More details here.
High-end manufacturers use expensive challenge-response schemes (the key sends a request, the car answers with a challenge, and the key sends a reply derived from the challenge with some algorithm).
Even so, such algorithms are proprietary, usually not reviewed, and could well be an example of "rolling your own crypto". There are solutions, but to quote the paper below,

Note, however, that a physical implementation of mathematically secure
ciphers still can be vulnerable to side-channel (typically power
analysis) attacks. Also the key distribution/management, when wrongly
implemented like with the Keeloq's manufacturer key, can introduce a
single point of failure into the commercial cryptosystem. In other
words, the chain is as strong as its weakest element, so the marketing
headword 'employes AES' does by far not mean that the product as whole
is secure.

Cheaper manufacturers use a rolling scheme employing a PRNG. Quite often, the car has a "guard period" after receiving a code, in which it will actively not recognize any code, to avoid bruteforcing. Several of these schemes actually relied on the secrecy of the algorithm, and have been broken (link to theory, practice and source code):

Recently it has been demonstrated how the manufacturer key can be
extracted from a receiver device by a physical side-channel
cryptanalysis and how a particular remote control can be cloned
(either knowing a matching manufacturer key without physical access to
the remote, or without manufacturer key but requiring physical access
to the remote)

Still cheaper manufacturers employ a rolling scheme between N codes, which is vulnerable to replay attacks (you get one code) or "stalking" the garage until you get enough codes.
Another vulnerability of remotes is jamming. You stalk a parking lot and fill the 433 MHz band with noise. Out of every ten people that lock their cars with a remote, nine of them will notice that the car lock didn't actually engage. They'll try again, blaming the batteries on the key fob, and finally lock the car manually (or succeed by transmitting from a few inches, which will further convince them it's the fob battery's fault). Maybe one driver in ten will walk away blissfully unaware that his car was actually left unlocked. You can spot him from afar (he's the one who did not turn back) and rob him blind: no need for sophisticated crypto at all. A 433 MHz transmitter and a white noise generator are enough.
Case in point
Your aftermarket key uses a KeeLoq HCS200. This has been proved and confirmed to be insecure:

KeeLoq remote keyless entry systems are widely used for access control
purposes such as garage openers or car door systems. We present the
first successful differential power analysis attacks on numerous
commercially available products employing KeeLoq code hopping. Our new
techniques combine side-channel cryptanalysis with specific
properties of the KeeLoq algorithm. They allow for efficiently
revealing both the secret key of a remote transmitter and the
manufacturer key stored in a receiver. As a result, a remote control
can be cloned from only ten power traces, allowing for a practical
key recovery in few minutes. After extracting the manufacturer key
once, with similar techniques, we demonstrate how to recover the
secret key of a remote control and replicate it from a distance,
just by eavesdropping on at most two messages. This key-cloning
without physical access to the device has serious real-world
security implications, as the technically challenging part can be
outsourced to specialists. Finally, we mount a denial of service
attack on a KeeLoq access control system. All proposed attacks have
been verified on several commercial KeeLoq products

This is not so much due to a shortcoming in KeeLoq's algorithm but in its practical implementation by the vendor. As such, there are claims that an aftermarket key can actually be fixed:

If your receiver device contains a
specialized hardware KeeLoq decoder, it should be possible to flash
your own randomly selected device code into that chip and matching
remotes, following the instructions in appropriate data sheets. In
this way you circumvent the problem with the learning algorithm and
manufacturer key.

(Along with a bounty of information, the page explains why my old garage remote happened to also open the University gate, as I discovered one sleepy morning when I inadvertently picked up the wrong remote - different on the outside, the two receivers must have been identical on the inside).
Update: buttonless fobs
A variation on the concept of "car remote" is the fob. This is normally a passive device (no batteries). It contains a coil that absorbs the nearby electromagnetic field, and if it is powerful enough it awakens and is able to modulate its own absorption. As a result, whatever is transmitting the electromagnetic driving field will experience a sequence of short power losses. By representing a power loss with a 1 and normality with 0, the driver unit will receive something like 000000000...0001101010101110011. The sequence is usually always the same (very high-end units implement challenge-response) and is unique for every fob.
The same or similar technology is used in some contactless cards and keys.
Since this kind of electromagnetic coupling only happens at very short distances, the fob is considered "safe". It most definitely isn't.
Attack 1: while the driver unit is massive (and usually mounted inside a car), it is possible to install one in a suitcase. Pass within one meter from the victim (whose will awaken, believe itself near the car, and transmit the unlock code). Record the unlock code. Profit.
Attack 2: much more expensive, but effective against USD 100,000 cars, so possibly worth your while. Requires two suitcases connected via Internet (put one Android phone in "personal access point mode" inside each for USD 79,98). The first is the same suitcase as above, but it does not record the unlock code, it transmits it to the other suitcase. A coil in the second suitcase starts siphoning energy from the car transmitter. The following "dialogue" (classical man-in-the-middle attack) ensues in the next few milliseconds:

SUITCASE 1: (absorbing)
CAR: (sleepily)...is there a fob nearby? Who's drinking me energy?
SUITCASE 1: Yes, I'm a fob. I'm your fob.
CAR: let me generate a random unguessable number: 12345. Add yours. What's the answer?
SUITCASE 1 (to suitcase 2): get me the answer to 12345 +.
SUITCASE 2 (to fob): My number is 12345. Add yours. What's the answer?
FOB: It's 73219.
SUITCASE 2 (to suitcase 1): 73219
SUITCASE 1 (to car): It's 73219.
CAR: You're correct. Alarm deactivated, unlocking door. Have a nice day.

UPDATE: and now they did it on CCTV, and the "suitcase" is no larger than a box.
This kind of vulnerability requires a contactless, buttonless fob, and can be protected against by wrapping the fob in electromagnetic shielding. This is not the same thing as aluminum, which protects against radio waves. Magnetic coupling is best shielded by iron foil or special magnetic shielding. Also keeping two identical fobs (of different cars) in close contact will work, if riskier, because by transmitting different codes on the same frequency they're liable to confuse the receiver.


Bypassing header validation I have made a script that can be used for exploiting CORS misconfiguration.
The script works fine but if I want to send an extra header to the request by
xhttp.setRequestHeader("test_header", "test_value")

It first sends the pre-flight(OPTIONS) request that contains
Access-Control-Request-Headers: header_name

which the server denies and cancels further requests.

Problem Scenario:
Suppose there is one header "test_header" which is allowed by the server

Original request:
sending "test_header"

Original response:

Access-Control-Allow-Headers: test_header

Success
Now sending the same header via CORS script:
xhttp.setRequestHeader("test_header", "test_value")

Sends a pre-flight request with Access-Control-Request-Headers: test_header.
response:

HTTP/1.1 200 OK
Content-Length: 0
Date: Wed, 27 Nov 2019 18:19:29 GMT
Connection: close

No more then this

So is it possible to add this header in the request without sending options request?
Can the request be proxied somewhere which then adds the header to the server?
Is there a way to send a header to the server from the victim's computer which then validates the header and sends the response?

So is it possible to add this header in the request without sending options request?

No. Anything but "simple" requests will cause a preflight requests. Simple requests are everything you could do without XHR, i.e. with an image include, form submit etc. Adding new headers will result in a non-simple request and thus will cause a preflight request.

  Can the request be proxied somewhere which then adds the header to the server?

CORS is only enforced in the browser. If the browser sees this as a simple request since the header is only added by a proxy, then the browser will not send a preflight request.


How can cloudflare read encrypted request without private key? We have Cloudflare in our production server and the encryption level is full, not flexible.
This webpage said Cloudflare can decrypt the request. But we didn't give our server's private key to cloudflare. How this even possible? Does this mean anyone can decrypt the request without target's private key?

One of the ways you use cloudflare is by setting the NS records for your domain to cloudflare's name servers which in turn resolve www.mydomain.com to their IP addresses. This means that when you go to www.mydomain.com setup with cloudflare, it hits one of their servers. The SSL certificate for that domain is not yours, it's theirs. Check the SSL certificate for your website, you'll see that it was issued to something.cloudflaressl.com and your domain is just one of the many in the Subject Alternative name.

The "Full SSL" setup just means that all client traffic to cloudflare is over SSL (using their certificate), and all traffic between cloudflare and your actual server is over SSL as well (using a certificate matching your server name).

As you can see, cloudflare by definition decrypts all traffic for your website but it can do so because cloudflare technically is your website. Your actual server is just something cloudflare grabs data from when it doesn't have it cached. If you think about it, how else would it cache anything?


What is this service? Fairly new to infosec and am going through a course on nmap. While scanning I found this and it looked interesting and was wondering if you all had any information on this?

This is the port,state and service in question.

464/udp   open|filtered kpasswd5

The fact you're seeing this service and port suggests you may be scanning a Domain Controller, for which both UDP & TCP ports 464 are used by the Kerberos Password Change.
This port in particular is used for changing/setting passwords against Active Directory.

Doing an nmap -A might help you identify which version is being run and could assist in helping you work out what type of attack it's vulnerable against.

On a side note, if you're like me and find it useful to know why that service exists, the one in question has a good read up here.


How difficult is it to protect your storage from data recovery Many of my customers refuse to sell or recycle their old hard drives or mobile phones because everybody now-days talks about how popular data recovery program's are. Isn't it enough to use a software to write a zero to every byte of the storage area in order to protect your deleted data?

What am I missing here? Are there other ways to recover the data? Why do some programs do more than one pass , this sounds silly

Yes, it will be enough to fill the drive with zeros to defeat any data recovery program. However, a specialized laboratory breaking apart the drive and using special tools to inspect the platters may still be able to recover some data.

Tools for disk wiping overwrite the contents several times with some patterns (eg. 00, FF…) and/or random data with the goal that such recovery can't get anything useful.


Classifying Reflected and DOM-based XSS Having referenced Difference between DOM & Reflected XSS
, I observed that certain attacks could be both DOM-based and Reflected XSS. I wish to find out if my understand is accurate, or they should be mutually exclusive. I have some examples that I have found to overlap in the two categories:

  URL

Reflected: http://example.com/index.php?user=

DOM-based: www.mywebsite.com/logon.asp?user=

  Body

Reflected:

DOM-based:

  Redirect

Reflected: XSS

DOM-based: document.write('Home');

And many other types of various reflected XSS like inserting image tags, iframes, HPP etc.
I am aware that for DOM-based xss, there are no round trips to the webserver, and commonly leverage on the "#" in the url to writes this value directly into the webpage.

I observed that certain attacks could be both DOM-based and Reflected XSS

No. What you list are the same payloads for both DOM based and reflected XSS (both attacks are often exploited in similar ways). But what happens underneath that is still either DOM based XSS or reflected XSS (well, or stored XSS). It's never both.

The names for the different XSS types do not specify how an attacker will attack someone, but how the attack works. As you noted, both DOM based XSS and reflected XSS might be exploited the same way, eg:

http://example.com/index.php?user=<script>alert(123)</script>

But with reflected XSS, you will have a server-side script, which will take the user argument, and then place it into the HTML document it returns to the user.

On the other hand, with DOM based XSS, the browser will take the user argument and then place it into the webpage.

So the difference is how the payload ends up being executed user-side, and that can happen one way or the other. But it can't happen both ways at the same time*

well, technically, it could if the server as well as the browser place the payload in the website, but that's not really the point.


Deletion of trusted root certificate store folders in a product I'm developing a headless linux based industrial safety product. It is very much limited to work with only known sources/hosts. Can I safely delete the trusted root certificates provided by the OS and Mozilla. Though I had not enabled mozilla in my target packages configuration, I see the certificates in the Root File system.
I do have some use cases for TLS communication, but it uses my own organization's two-tier PKI CA environment and the CA-bundle is explicitly included in the root file system using overlay feature.
So can I safely delete the below folder contents?

OS provided trusted root cert store /etc/ssl/certs/
Mozilla provided trusted root cert store
/usr/share/ca-certificates/mozilla/

Yes, you can.
If your appliance is not designed to communicate with any external hosts, then creating your own certificate store, which only includes CA's you manage, is a reasonable thing to do.
It doesn't really add that much security, given that breaches of any of those CA's are very unlikely, but it doesn't have any negative effects either.

While it is not 100% directly your question, there is a design pattern many developers fall into that can lead to vulnerabilities.
Many developers use client certificates signed by a CA they control in order to provide a mechanism for authentication. However, they only check if the certificate is valid - not if it is actually signed by their own CA. This means an attacker can generate a valid client certificate through a public, trusted CA and use that to authenticate with the service.
While deleting all external CA's would solve this problem too, the inclusion of a check whether or not the presented client certificate is signed by the correct CA is a much better solution.


Best ways to store private keys on a client? I am currently writing a program that sends an encrypted file to the client, and I don't want the user to be able to access the file directly (though the client program will operate on it).
Since the client will be written in Java, which is prone to reverse engineering methods like decompilers as well as things like javaagent, ASM, and reflection, I got stuck on how I would be able to send the private key safely to the client application.
Currently, I have two ideas:

Include the private key with the jar file
Send the private key over HTTPS after the client runs and cache it in memory

However, with case 1 I am unsure how I would include the key in a jar file if I don't want the user to be able to access it; and with case 2 I am worried about the user intercepting HTTP packets.
What should I do to keep the data as secure as possible?
Thanks

Essentially, the problem you are trying to solve is the same as DRM. It is practically impossible to securely store secrets client side (at least without specialized hardware), since the user has unlimited access to the client and can modify and inspect it at will.

Include the private key with the jar file

As you say, the user can easily reverse engineer and recover the private key. Obfuscating the key may make it harder to retrieve the key, but any decent determined reverse-engineer will eventually be able to recover it.

Send the private key over HTTPS after the client runs and cache it in memory
I am worried about the user intercepting HTTP packets.

To solve this specific problem, you could use certificate pinning to prevent the user from simply using some sort of TLS inspection proxy to intercept and inspect the packets. However, a reverse engineer could remove the restriction from your application. Or they could just dump the memory and retrieve the key from there.
If you are trying to prevent casual users from being able to extract the key, hardcoding the key along with some obfuscation should be sufficient. However, if you want to prevent an experienced reverse engineer from extracting the key, you are out of luck.


Trying to build an open authentication controled authorization website for multiple domain users I'm not sure that this is possible but I figure at worst, I'll be told you cannot do that.

Our organization has a report server that sits in a DMZ accessible by multiple units that have their own Active Directory Domains. There is no internet access to the DMZ (which is the only reason I'm even considering this solution as I realize that it is a big reduction in security). The server uses an authorization database to control what links and panels are visible and accessible to the viewer. No passwords are stored in the database, just Domain\Username combinations.

What we would like to happen is this. We want to rely on the fact that if the user had signed into their own system and had authenticated against their AD, then they are who they say they are. We would compare their user name against the authorization database and grant them access based on their roles.

We cannot use IIS Anonymous Authentication because we cannot access the viewer's logged on user name. Using any other Authentication doesn't work because the site then asks for user name and password which we cannot authenticate against multiple domains.

Essentially we want to short circuit Windows Authentication so that we automatically allow them to see the site but we can also retrieve the viewer's domain and user name.

I've looked at many SSO posts but all of them require the viewer to sign on once at the website level and/or deal with multiple sites across the domains. It seems to be a bit of overkill for this project to build out an SSO domain for one site that will only be accessed internally.

Automatic authentication does only work for manually configured proxies (eg, when a browser is set to use a proxy, it can be configured to do a automatic "windows authentication" to this proxy) for obvious security reasons - the reason is that else, any site in the whole world would be able to obtain valid hashed authentication credentials, which could be used in pass-the-hash attacks.

But there is a solution you could use:
Configure your AD server, to record the client IP of the computer in question, along with username/domain, when it has authenticated. And configure the AD server to delete this record of IP when a computer logs out.

Then, in the intranet site in question, you use the client IP to query the database that AD created, and check which username it is.

Of course, this wouldn't, as you say, give high security, but it would atleast give some security, while still having the convience of not having to login all the time.


What should I do during the Man in the middle attack? I have a question about Man in the Middle attack.

  What should I do during the Man in the middle attack?

In case I am already connected with a friend of mine on the net, but I suspect that there is a third party among us who is reading or modifying mine and my friend's messages. What do I have to do?

First, I thought that I need to close the initial connection and create a new one with authentication.

I had also thought of establishing a TLS connection with my friend, so even if the channel remains unsafe, the CAs would guarantee network security. I just thought ... The man in the middle can intercept the CA's responses and get him authenticated in my place.

What do I do if I have this suspicion of attack?

This answer is inspired by my conversation with MechMK1 in the comments.  The problem that MechMK1 points out in the comments basically boils down to authenticity, which is often seen as the achilles heel of public key cryptography.  How can you be sure the public key purporting to belong to the person that you are attempting to connect with really belongs to that person, and not an MITM?

One way to verify the authenticity of the other party's public key is to use use an out-of-band channel, such as SMS, fax, phone, postal mail, etc.

But, as MechMK1 points out, it's possible that the attacker may be able to intercept connections in these other bands as well.  Not many attackers have the ability to this, but it's not out of the realm of possibility for a three-letter agency or a nation state.  In this case, sneakernet (exchanging public keys in person) may be the most secure way to verify the authenticity of the other party's public key, if possible.

But, if sneakernet is not an option, due to proximity, time constraints, logistics, etc., then another option is to use a trusted third party, who's public key we know, to verify the authenticity of the other party's public key.  This is what SSL/TLS does, using certificate authorities (CA's).  PGP does this using a web-of-trust model.

But we know that neither of these are perfect solutions.  Perhaps the most notorious example of this was the incident involving the CA DigiNotar in 2013.

Moreover, if the CA or trusted third party is not able to verify the authenticity of the other party's public key in person, then the CA or trusted third party must connect to the other party through some network.  If the attacker has as much reach as we are assuming for the sake of this question, then the attacker can simply MITM that connection as well.

To summarize, there is no perfect solution to this problem.


Bypass Text Plain Rule I want to know if I can allow uploading all types of scripts and add these rules to a virtual host configuration; so please advise and tell me if there will be some  exploits that can be used to bypass this security rules ( if yes please how to block it)

Thanks in advance,
Maybe this question has been answered earlier but I don't know how  to get the right  results.

There are a few things you can do to mitigate the risk:

Try to upload the files to a path outside your webroot

For example, if you host your site on /var/www/myserver/html, make your PHP upload script write files on /var/www/myserver/data.

This way, a Local File Include will not work, as the sent files are outside the server root.
Don't use Mime Type or file extension to determine the file type

It's easy to forge Mime Type and file extension. Instead, use PHP Fileinfo functions to identify the file.
Don't store the files with the original filename

Always rename the file to something unpredictable, like a hashed salt. Doing this makes harder to an attacker to predict and use the file he just uploaded.
Make sure your error messages are not leaking data

If your error message says File webshell.avi not found on /var/www/myserver/data, you are leaking precious information. On a production server, don't enable error reporting, or send them to you, not the client.
Use a script to read the files and send the data to client

Don't link direct to the files, but have a script read them instead. This way you can sanitize the data before sending, and the raw files will not be processed by your server.


Why do PGP master keys only have a single subkey, and tie certification with signing by default? After learning more about PGP subkeys and how to split apart the roles of (S)igning, (E)ncryption, (A)uthentication and (C)ertification, I discovered that in most cases(?) a default master key has a subkey to separate out the job of encryption:

pub  2048R/AAAAAAAA  usage: SC
sub  2048R/BBBBBBBB  usage: E

Here, AAAAAAAA is the master key. S allows signing content, C allows creating new subkeys. (One benefit of this being that you can give AAAAAAAA a longer expiration time than BBBBBBBB and then create a new encryption key with AAAAAAAA because it has C usage permission.)

However, it seems to me that the following would be no less secure for users working off a single machine, yet provide more security for users who wish to receive encrypted mail from, e.g., work and home:

pub  2048R/AAAAAAAA  usage: C
sub  2048R/BBBBBBBB  usage: E
sub  2048R/CCCCCCCC  usage: S

With this setup, the master key AAAAAAAA cannot sign/verify or encrypt/decrypt, yet can collect trust. Thus, you can give the master AAAAAAAA key a longer expiration time and use it to add new subkeys. By then exporting BBBBBBBB and CCCCCCCC to, say, a separate work computer that is moved around a lot more and is less secure, without the master key, if the work computer is compromised, subkeys can be revoked and new keys added, without losing any reputation.

(You can even go as far as to keep the secret part of the master certification key in a Super Secure Secret Bunker, of course.)

I know that setting this up seemed to be impossible through a GUI (they don't seem keen on subkeys, either viewing or editing, let alone controlling what the master key can and can't do), but my question is:

Is there a specific reason this isn't done with existing PGP implementations? Exporting secret keys to other machines without certification privileges seems like it would be a big security win. (If only GUIs made it easier.) My only possible thought is that importing secret subkeys with a crippled master secret key is maybe not widely supported, as --export-secret-subkeys (in the gpg(1) man page) hints at:

--export-secret-keys

--export-secret-subkeys
       Same  as --export, but exports the secret keys instead.  This is
       normally not very useful and a security risk.  The  second  form
       of  the  command  has  the special property to render the secret
       part of the primary key useless; this  is  a  GNU  extension  to
       OpenPGP  and  other  implementations can not be expected to suc‐
       cessfully import such a key.  See the option  --simple-sk-check‐
       sum  if  you  want  to import such an exported key with an older
       OpenPGP implementation.

Edit: It looks like Debian follows this same practice? https://wiki.debian.org/subkeys

I have two viewpoints on this issue: one is based on historical facts (and is a bit technical), while the other is purely my own, original opinion.

Regardless, it seems indeed more secure, or at the very least more convenient, to use a separate key for signatures; that way, you only use your master key for certifications (and can store it away), and you don't have to go over all the certification process again (IRL meetings) if your key is compromised.

Historical facts

After carefully reviewing the C source code of stable GnuPG versions (1.4 and 2.0), I found the function responsible for setting the default capabilities of public keys; the code (in file g10/misc.c) looks like this:

476 int
477 openpgp_pk_algo_usage ( int algo )
478 {
479     int use = 0;
480
481     /* They are hardwired in gpg 1.0. */
482     switch ( algo ) {
483       case PUBKEY_ALGO_RSA:
484           use = (PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG
485                  | PUBKEY_USAGE_ENC | PUBKEY_USAGE_AUTH);
486           break;
487       case PUBKEY_ALGO_RSA_E:
488           use = PUBKEY_USAGE_ENC;
489           break;
490       case PUBKEY_ALGO_RSA_S:
491           use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG;
492           break;
...
509       default:
510           break;
511     }
512     return use;
513 }

I found this function because I first looked at how key generation was done (g10/keygen.c); it is indeed during (sub)key generation that GnuPG may give the "roles" for the keys. Once a master key is created, you cannot change its abilities.

The source code didn't tell much (except that a RSA key for signing also comes with the ability for certifying), but running a web search for the comment (line 481 above) led me to message a posted on 2005-08-03 in the gnupg-users mailing-list, saying:

  GnuPG does not yet distinguish between C and S.  So it does not make
  much sense to have a way of selecting this.

So, it seems that those default settings exist just because GnuPG used to make no distinction between the signature keys and the certification keys.

Additionally, these default settings may be in place because of DSA, as Simon Richter pointed:

  For quite some time, gpg used DSA keys by default, which can only be used for signing, and then had to attach an elGamal subkey (which can be used for encryption only) to get a fully functional key.

  For RSA, that isn't necessary, but it was kept for some reason.

  The "sign only" or "encrypt only" RSA subtypes are not technical limitations on the algorithm.

Original facts

Nowadays, I believe the only reason of that (default primary key capabilities set to SC and not C alone) is to help regular users with verifying signatures.

Let's say you have those two keys in your keyring:

pub  4096R/00000001  1970-01-01       usage: C
uid                  Alice Owl
sub  4096R/AE687A0C  1970-01-01       usage: S
sub  4096R/F77A9AF1  1970-01-01       usage: E

pub  4096R/FFFFFFFE  1970-01-01       usage: CS
uid                  Bob Penguin
sub  4096R/00FF42CD  1970-01-01       usage: E

Alice Owl is a regular GnuPG user, she is confident with OpenPGP and generated a keypair with GnuPG's --expert flag, so she could set her own key abilities. The primary key has the C flag of course, but she signs documents with a subkey.
Bob Penguin knows barely anything about cryptography. The only thing he wants is a bit of privacy/intimacy. He generated his key like any regular user would (without touching any setting he doesn't understand).

Now, let's pretend you – the reader – are a beginner too. You receive signed documents from both Alice and Bob. You know the basics of gnupg, and in particular:

Users are identified with their primary keys:

So I know that Alice is 00000001, and I also know that Bob is FFFFFFFE.

One can verify messages with GnuPG's --verify or --verify-files options.

Now, let's verify the documents they sent to you.

$ gpg --verify from-bob.txt.asc
gpg: Signature made <date> using RSA key ID FFFFFFFE
gpg: Good signature from "Bob Penguin"

$ gpg --verify from-alice.txt.asc
gpg: Signature made <date> using RSA key ID AE687A0C
gpg: Good signature from "Alice Owl"

  Wait, what? I thought Alice's key was 00000001?

Indeed, signatures on documents are not necessarily made with the master key; they are made with the key which has the signature capability (S). It is unlikely a beginner would know about that.

Maybe the actual explanation has nothing to do with this assumption ("the more beginners using SC keys, the better it is for other beginners"), but that's the only explanation I can come up with without bothering the GnuPG contributors.


Is this website encrypted or not? This site: http://www.wootbox.de/

I would say no, because according to FF and Chrome it uses http
According to ssllabs.com and the support of the website it uses https: https://www.ssllabs.com/ssltest/analyze.html?d=wootbox.de

I also tried https://www.wootbox.de and https://wootbox.de but I get always http://www.wootbox.de

The URL https://www.wootbox.de/ exists for the sole purpose of redirecting you to the unencrypted http:// version using an HTTP "302" Redirect.  The 302 response below tells the web browser to resubmit their request to the "Location:" of http://www.wootbox.de/.

$ wget -S -O - https://www.wootbox.de
--2016-08-11 18:40:16--  https://www.wootbox.de/
Resolving www.wootbox.de (www.wootbox.de)... 104.45.3.115
Connecting to www.wootbox.de (www.wootbox.de)|104.45.3.115|:443... connected.
HTTP request sent, awaiting response...
  HTTP/1.0 302 Moved
  Date: Thu, 11 Aug 2016 18:37:55 GMT
  Server: Apache/2.4.7 (Ubuntu)
  X-Powered-By: PHP/5.5.9-1ubuntu4.17
  Cache-Control: no-cache
  Location: http://www.wootbox.de/
  Content-Length: 0
  Connection: close
  Content-Type: text/html; charset=utf-8

This would not normally be a problem - many sites prefer you use HTTP for non-sensitive actions to save on the overhead.  However, I notice that the login page is set to POST your credentials to the unencrypted HTTP address:

<form action="http://www.wootbox.de/anmeldung" method="post" id="login_form" class="box wootbox-auth">
  ...

  Passwort
  <input class="is_required validate account_input form-control" type="password" data-validate="isPasswd" id="passwd" name="passwd" value="">
  ...

This implies that the site is actively eschewing security, not merely redirecting browsers when security isn't necessary.

Tools like SSL Labs don't care about that HTTP redirect, so they probe the working SSL server for all their testing and provide you a report.  However, the application layer - the thing the SSL connects you to - tells your browser to come back without SSL, and so it does.


HTTPS POST request header versus request body Is there any security difference between placing sensitive data, such as an API key in a POST request header versus the POST request body assuming the API server is HTTPS-only?

While you frequently see API keys in the Authorization header or a custom X-API-KEY header, does placing the key in the header actually increase the level of security for the key or is this strictly an API design convention?

If the transport itself is secured (i.e. https) an attacker can not sniff the data. But it might be logged at the server side and the server might later be compromised or some security leak might cause the log files to be publicly visible. Such log files usually contain the URL and they might contain other lines from the headers like User-Agent, Referer and other headers if specified with a custom log format. Thus it might be a bad idea put these API keys into the request header, unless you make sure that they don't get logged.

An argument against putting the key in the request body is that it now would be possible to create a simple HTTP form which includes the key which is easier to be used as a CSRF request. When including the API key as header instead the attacker must be able to do a XHR request and is subject to the restrictions of CORS.

Another reason for not including the key into the URL is that it might get included into the Referer header of a following request. Also the URL's are usually contained in the browsers history so that you have another place which could be compromised. This is relevant only for normal browser requests, i.e. XHR or REST requests done by applications are not affected.

Some explanation about the meaning of "header": sometimes one uses the name 'header' to distinguish the initial part of the HTTP message and the body. In this case the URL is part of the header (request line). Other times one talks about the headers (plural) and means the "field:value" pairs only, i.e. not including the request line with the URL. It is not fully clear for me which meaning is used in the question so I better covered both.


Malwarebytes Block Outbound Connections (Guest-to-Host On VBox) While I am using other OS (Mostly Linux) in VBox and start Downloding from torrents,
the host (Windows 10) that I have Installed Malwarebytes block Outbound Connections?

Can it be dangerous when the trial ends
[

It seems you are downloading from a suspicious ip. Maybe that ip is in a blacklist... and that kind of things usually is because of a reason.

Torrent downloads are usually a way to propagate malware... so could be dangerous. Keep your eyes open and check carefully what you download before opening it, that's all.


How to defend against a Spoofed-IP Blacklist DOS attack? So I've implemented an IP Blacklist for the /login endpoint on my server.

If any IP fails to login more than x number of attempts in x number of minutes the requesting IP is blacklisted for x number of minutes.

That goes a long way in mitigating any brute-force attacks attempting to determine a users password by adding large delays to the mix when too many failed /login requests are received by any given IP.

But there's a scenario where this could be problematic, and actually be an instrument for an attacker to launch a DOS attack agains my legitimate user, like so:

Blackhat wants to DOS LegitUser's website
LegitUser has a server with the IP 11.22.33.44
LegitUser's server needs to communicate with my system in order to remain online.
Blackhat finds out what LegitUser's server IP is
Blackhat uses a proxy server as an IP-Spoofing machine to send a large number of purposely unsuccessful /login attempts to my system, knowing that these failed attempts will get the requesting IP (which has been spoofed to be 11.22.33.44) blacklisted.
Blackhat doesn't care if he receives a response from my system for the  purposely unsuccessful /login requests because the point of this attack is not to brute-force any credentials, it's to trick my system into believing that the IP 11.22.33.44 has exceeded its allotted login failures for any given timeframe.
The result is that the IP 11.22.33.44 is blacklisted by my system. But, this IP does not belong to Blackhat, it belongs to LegitUser, who has played no role in this attack at all.
The result of the blacklisting of the IP 11.22.33.44 is that the website served from that host is now offline, because it depends on my system to remain online.

How could I go about protecting against this?

According to several of these answers:

https://serverfault.com/questions/381393/can-the-ip-address-for-an-http-request-be-spoofed

It is really unlikely that you could indeed spoof the IP address and send a full HTTP request to a server. TCP requires a three-way handshake, which means sending one packet back to the sender and expecting a very specific answer back (with a number that is expected to be random, 10+ years ago, that number would just be incremented so it was possible to more or less guess the next number and thus send a "reply"--second request really--with the data and thus the HTTP request itself).

With that in mind, blocking an IP address is a good way to prevent wasting bandwidth to satisfy a robot thirst in an attempt to log in an account. Many systems offer this capability and most, like yours, do it temporarily. Actually, I generally set mine up to block that account for 1 whole day because I've seen many attacks lasting at least that long. That being said, my websites are not like Facebook or Twitter where people come back several times a day pretty much every day... So it will depend on your business model, who uses your systems, how much, how often they need to log in or log back in, etc.


Can I be sure a Word document is safe if it doesn't have macros I am aware that MS Word documents can be potentially dangerous due to the executable macros contained within them.
But for a particular document, I have opened the macros and can see there are none. Can I be sure, therefore, that this document is not malicious?

Macros is the major risk associated with word documents. But it is not the only one.
It is possible that there is some sort of code execution vulnerability in Word, that allows a malicous word document to spread malware on your computer. Such a vulnerability would be a pretty big deal, though, and personally I would not worry about it.
Is there a way to make Word documents make HTTP requests? I am not sure, but if there is, the risk would be similar to clicking on a link on a webpage.
The content of the word document could also be used for social engineering, but here it is you rather than Word that might be vulnerable.
Personally, I open word documents without macros from untrusted sources without thinking twice about it.
(A side note: If you have opened the word document to check for macros, you have already exposed yourself to risk. For the modern MS Office file formats, you can use the extensions to check for macros - .docx does not allow macros, while .dotm do.)


Network setup for malware analysis lab in a corporate view I am planning to setup a malware analysis lab in the Incident Response team of the company I work for.

As I am basically a malware analyst I some how managed to get up with the malware analysis lab setup.

Now I want to your help in setting up network for the lab.

Here are the scenarios:

I don't have my lab setup in a physical machine next to me, It was set up on a remote machine and it is having a open network connection.

Please tell me how to connect to my lab as I am in my corporate production network, as it is not advisable to connect to a malware system from production environment.

I also have lab going get setup in my client location, so please tell me how to connect to the malware lab, since I have to cross two production environments i.e. my own corporate production environment to our clients production environment and from there to the malware analysis environment.

Virtualized Environment.

Set up a series of virtual machines on virtual networks in a host that is in its own segmented network (VLAN, firewalls, no outward connections allowed, etc.). Run all your analysis in this environment. You connect by connecting to the host, then from there to the virtual machines. Even if malware runs rampant, you only risk the other VMs.

In the off-chance that malware from the VM escapes to the host machine (still uncommon at this point), it is segmented off from the rest of your network.

Being in a closed virtual network, you are more free to set up network traffic analysis to analyze the network connections generated by the malware, without affecting your corporate networks.

The other benefit to VMs for malware analysis is that you can blow away the VMs and restore them to an original image. This should be scheduled on a daily basis (or more often) in case there is an infection that you do not catch or fully understand. This prevents a persistent infection in your environment.

This set up also solves your problem of connecting across multiple networks. A simple VPN will allow you connection to the host machine without fear of malware traversing the VPN.


Alternative to Avast Safezone for banking Apparently low level keyloggers etc can intercept typed details before Safezone keylogging protection kicks in. Would BD Safepay avoid this problem with its enforced virtual keyboard ? Or perhaps Sandboxied browser with real time Zemena antilogger encryption and MBAE injected . Which safest option please for banking .

Would BD Safepay avoid this problem with its enforced virtual keyboard ?

Not completely: It would mean that actual keyloggers would no longer be able to intercept your keystrokes. In fact, this is why some banks require you to enter your password by clicking on-screen buttons. However, keyloggers have adapted, and some have also become "mouseloggers", which means that even with a virtual, on-screen keyboard you may not be safe, since these will take screenshots of what and where you click.

  Or perhaps Sandboxied browser with real time Zemena antilogger encryption and MBAE injected

Not really: It will make your environment more secure, but it won't gurantee anything. Zemena is basically an antivirus, and, if it does not detect the keylogger, you're out of luck. MBAE is similar: It won't help you if it doesn't detect the malware.

Tl;Dr: "Low-level" keyloggers could intercept your keystrokes and any other actions, no matter what you do.

What I'd recommend, as a "kind of" alternative: Use a system which you know is not infected for your online banking. A Linux live CD could be used for this purpose. Also, If Avast or another antivirus tells you that you're safe, you probably are.


set newline or slash through URL There is an option to set date range through URL address bar like this

domain.tld/process/date_range:2017-04-13%7C2017-05-02

GET parameter is parsed in PHP like this

    ...
<?php if(isset($dateTo)): ?>
    endDate: moment("<?php echo $dateTo; ?>", "YYYY-MM-DD"),
<?php else : ?>
    ...

and the this is echoed directly to javascript

<script>
$(document).ready(function() {

    $('#r').daterangepicker({
        startDate: moment("2017-04-01", "YYYY-MM-DD"),
        endDate: moment("2017-05-1", "YYYY-MM-DD"),
        ...

so i am trying to modify GET param by adding

")%7D);console.log(1234);});

then i am able  to get

<script>
$(document).ready(function() {
    $('#r').daterangepicker({
        startDate: moment("2017-04-13", "YYYY-MM-DD"),
        endDate: moment("2017-05-02")});console.log(1234);});", "YYYY-MM-DD"),
        ...

but line

endDate: moment("2017-05-02")});console.log(1234);});", "YYYY-MM-DD"),

generates syntax error and then console.log(1234) is not interpreted.

How can I get that working?

its internal project

You code has at least one closing bracket too much. You need to properly comment out the junk at the end (with // or /*):

        endDate: moment("2017-05-02")});console.log(1234);});", "YYYY-MM-DD"),
                                                             |---------------|

But in your example, the easiest XSS payload would just be:

",console.log(1234),"

Instead of adding an extra statement, this injects console.log as an expression.

If you don't want to mess with the Javascript syntax (and angle brackets are permitted), you can also just close the script block and open a new tag, like so:

</script><svg/onload=console.log(1234)>

This works because the syntax error you're producing in the previous script doesn't block other independent scripts on the site from executing.

(Slashes can be URL-encoded as %2f and newline characters as %0a or %0d%0a, respectively.)


Kali Linux browser_autopwn2 WINXP IE6 I'm new at Kali and Metasploit in general. I've been trying for a few days to discover it, and I'm a bit stuck when trying to exploit a VM running Windows XP and with IE 6.

Here are some screenshot from msf:

Options:

Before I connect with IE 6 from the VM:

When I  connect, this is where browser_autopwn2 blocks:

And it just hangs there... I'm pretty sure I should be able to exploit a Win XP machine with IE 6. I probably set some things wrong, if someone can help me, Iwould really appreciate it.

By the way, I also tried with Firefox 43.0.1 using the VM, and it doesn't work either, but it blocks somewhere else. Here is another screenshot:

It doesn't work because you chose the wrong exploit.

Looking at the comments of the KingScada - kxClientDownload.ocx ActiveX Remote Code Execution exploit (here), we can see that it

  abuses the kxClientDownload.ocx ActiveX control distributed with WellingTech KingScada.

If the target PC doesn't use WellingTech KingScada, which is a particular software deployed in industrial automation systems, the exploit won't work. This is the reason why autopwn2 blocks when the target uses Internet Explorer.

Even if that software was installed in the Windows XP machine, the exploit wouldn't work, because it is written to target Internet Explorer, rather than Firefox, as we can see from the following line of code:

  :ua_name     => /MSIE|KXCLIE/i

where ua_name describes the User-Agent string, and MSIE is the acronym for Microsoft Internet Explorer.

As a general rule, before launching exploits, you should always understand if it targets a particular operating system or browser, if it requires some plug-in (like Flash) or if it relies on the vulnerabilities of a particular software, as in this case.


How to find stack pointer for overflow bug? I've read that stack usually starts in same address so the attacker may guess the starting point of the buffer to overflow. This is necessary to know this address to make the malicious code run. I made a program with a few lines of code to get the stack pointer address each time it starts and print it on the screen:

int * get_stack_pointer(){
    __asm__("mov %esp,%eax");
}
void main(){
  printf("Address: %p\n",get_stack_pointer());
}

And this is disassembly of the program:

<get_stack_pointer>:
push   %rbp
mov    %rsp,%rbp
mov    %esp,%eax
pop    %rbp
retq

<main>:
push   %rbp
mov    %rsp,%rbp
mov    $0x0,%eax
callq  40050c <get_stack_pointer>
mov    %rax,%rsi
mov    $0x4005ec,%edi
mov    $0x0,%eax
callq  4003e0 <printf@plt>
pop    %rbp
retq

But each time I start the program I get different addresses. Some of these are as following:

Address: 0xc31b2c80
Address: 0x2e041e0
Address: 0x7b003190
Address: 0xb3fd1350

So in this case how is it possible for the attacker to run his code on the vulnerable program? (my OS is Linux 64bit)

EDIT: I made another program in assembly which includes a few simple lines. I just check the value of RSP every time it starts with debugger and I see always RSP has the same value but not the program written in c.

Your problem is ASLR randomly choosing where your program is loaded.  You can turn off ASLR in Linux using sudo sysctl -w kernel.randomiz_va_space=0.

Here's my program.  I'm using RAX instead of EAX, and an unsigned long * rather than an int *.

#include <stdio.h>
#include <stdlib.h>

unsigned long *get_stack_ptr(void) {
  __asm__(
    "mov %rsp, %rax"
  );
}

int main(int argc, char **argv) {
  unsigned long *stack_ptr = get_stack_ptr();

  printf("Size Of Ptr: %d bytes\n", sizeof(unsigned long *));
  printf("Stack Pointer: %llX\n", stack_ptr);

  return 0;
}

Here's my program on ASLR:

@narrator:$ ./stackptr
Size Of Ptr: 8 bytes
Stack Pointer: 7FFD328233D0
@narrator:$ ./stackptr
Size Of Ptr: 8 bytes
Stack Pointer: 7FFC2B5F07E0
@narrator:$ ./stackptr
Size Of Ptr: 8 bytes
Stack Pointer: 7FFFE3A2FF10
@narrator:$ ./stackptr
Size Of Ptr: 8 bytes
Stack Pointer: 7FFE5F0795F0

Now I perform: sudo sysctl -w kernel.randomize_va_space=0

Here's my program without ASLR:

@narrator:$ ./stackptr
Size Of Ptr: 8 bytes
Stack Pointer: 7FFFFFFFDF70
@narrator:$ ./stackptr
Size Of Ptr: 8 bytes
Stack Pointer: 7FFFFFFFDF70
@narrator:$ ./stackptr
Size Of Ptr: 8 bytes
Stack Pointer: 7FFFFFFFDF70
@narrator:$ ./stackptr
Size Of Ptr: 8 bytes
Stack Pointer: 7FFFFFFFDF70


Should I allow incoming traffic from source port 443? I am hosting a web server, both standard and SSL. Both work fine currently.

In my logs, I've noticed what seems like a distributed port-scan: 10-15 port queries from random hosts occuring within seconds of eachother every few hours.

I have fail2ban up and running, but since the source IPs are always different, it doesn't catch this kind of attack. The destination port is always different, but the source port is always 443.

Is an effective way to block this attack to block packets with source port 443, or is that going to interfere with my https server?

Thanks!

I wouldn't.

Your attacker is already distributing scans across IP, which is much harder to do that distributing across ports. Blocking a port would only send you down a rabbit-hole (what happens if they change to port 80, 21, 1024....etc)

The real downside is that this could create future operational issues for you down the road, you never know when you might need some packets with source port 443.

Probably worthwhile to run a full scan of the box to see what open ports there are on it, before the attacker finds them.