Based on experience, I'd say that it is not that likely that you are being continuously attacked, check for hardware errors, especially disk corruption causing odd errors before assuming an attack as that is far more likely.

However, to answer the actual question, one way would be to install a Syslog Agent so that Windows events are passed out to a syslog server. You will need to configure such a server of course but that is easily done using a Linux computer which could be a simple single-board computer such as a Raspberry Pi.

Solar Winds provide a simple syslog agent for free. THere are other options of course.


Is it possible to compromise Bing to redirect user to a malware?

That's not the way it happened.

There are cases of ad networks presenting malware, but generally the ad network has been fooled. The hacker generally creates a innocent site, and buys ads from a network (Bing can be one). So, as soon as he gets traffic coming from Bing, he changes the site to install malware.

So, Bing was not compromised, but the site was changed after being submitted. Bing, Google, Yahoo and others scan the sites they point to, searching for malware. But they cannot find every instance of this attack.


Can iPhone get malware plugged into life fitness cardio machine?

As you realized yourself there is some kind of data exchange between these devices. While the exact nature of this data exchange is unknown it would not be the first time if bugs in the interpretation of received data resulted in exploits since commonly the applications don't expect malformed data. In summary: communication path is there and all the attacker needs now is to find an exploit which works over this path.


Should statically-linked server binaries (daemons) be deemed more secure?

From a security standpoint, static linkage has one advantage and one weakness:

The advantage is that a statically-linked binary is immune to library injection attacks.

The weakness is that it cannot be protected by ASLR: the address layout was determined at link time, so the OS is unable to randomize the location of executable code.

Library injection requires local access, while known-address attacks tend to be remote, so on the whole, I'd say that static linkage of server binaries is a net negative to security, in addition to its other drawbacks.


Not able to find "SSH-" string in payload [Port Independent Protocol Detection]?

The first packet from both client and server is the only payload that contains SSH-. Which is when both the client and the server are attempting to determine the cryptographic parameters.

If you want to parse SSH you'll need to fully understand the SSH protocol.  Even after parsing the handshake you still won't be able to decrypt the application layer payloads.  Unless you dump the keys in some way.  I know PuTTY allows you to debug SSH sessions in that way.  So it depends on what your goal is for sniffing.

Programs like Wireshark label protocols based off of port numbers.  If you setup an SSH daemon on port 4444, and SSH to it; Wireshark will likely just say that it's TCP.


Malicious self-executing code can only exist in EXIF data in JPEG images?

Not necessarily.

Malicious self-executing code take advantage of bugs affecting the code of some software handling the data. You refer to a bug in the way EXIF has to be processed, but the picture data also has to be handled by the software and the code handling this data might also have bugs which could potentially be exploited.

Removing EXIF data will protect against threats trying to use bugs affecting EXIF data manipulation, but it will not do anything against threats trying to exploit actual picture data handling routines (for this you may imagine an image resizing which would alter the picture data, however you may want to take measures so that the software making this resizing cannot be exploited successfully...).

In all case, such threats can only target very specific versions of software and libraries, since they target a very specific bug they cannot be some kind of "generic exploit" affecting all users opening the image no matter with which software.

Edit: A discussion on this subject can also be found in StackOverflow.


Scrypt is supposed to be "better" than bcrypt, but is is also much more recent, and that's bad (because "more recent" inherently implies "has received less scrutiny").

All these password hashing schemes try to make processing of a single password more expensive for the attacker, while not making it too expensive for your server. Since your server is, basically, a PC, and the attacker can choose the most efficient hardware for his task, password hashing schemes try to be such that the best platform for them will be a PC. PBKDF2 can be thoroughly optimized with GPU, while bcrypt and scrypt are much less GPU-friendly. Bcrypt and scrypt both require fast RAM, which is a scarce resource in a GPU (a GPU can have a lot of RAM, but will not be able to access it from all cores simultaneously).

It so happens that modern FPGA embed many small RAM blocks which are very handy to optimize a parallel dictionary attack with bcrypt: this means that an attacker will get a huge boost by using 1000$ worth of FPGA instead of 1000$ worth of generic PC. This is the kind of boost that we want to avoid. Hence scrypt, which requires a lot more RAM; not too much for a PC (we are only talking about a couple megabytes here), but enough to make life hard for a FPGA (see this answer for a detailed treatment of the question).

Thus, theoretically, scrypt should be better than bcrypt. However, this is all subject to whether scrypt lives up to its cryptographic promises. This kind of guarantee of robustness can only be achieved through time: the scheme will be deemed secure if it survives years of relentless assaults from cryptographers. How much time is needed, is of course a bit subjective, and also depends a lot on exposure (the more widely deployed a scheme is, the more "interesting" a target it becomes, in that breaking it would increase the academic fame of the perpetrator; thus attracting more scrutiny). My own rule of thumb is to wait for about 5 years after publication, thus 2014 in the case of scrypt.

There is also the question of availability: if you want to use a function, then you need an implementation which can be inserted in the programming framework you use.


"Is it safe to throw away debit card receipts in the bin?" yes and no, factly its just the principle of keeping notes with private information tight with you (every piece of info is costly and reserved). Are DCR's highly detailed and full of information (which normally are not) and is your bin on the edge of street, then you can see this as a potential risk. But in reality, this is not that important if you are working in a well ruled company. Of course someone would have interest in this, but likely doing nothing with it.

There is another option: use an alcohol based marker or black ink, mark the most important lines.

Would it be any more worth while burning/shredding receipts before throwing them away? Now you are free-of-risk.


Self-signed certificate for a IdP-initiated SAML SSO

TL;DR: Self-signed certificates are fine, and even recommended at least in some contexts. Use long validity times to avoid key rollover problems, and if RSA, use at least 2048-bit keys.

SAML 2.0 includes the certificate that should be used for signature validation and as an encryption recipient as a part of the SAML metadata (technically, within the EntityDescriptor).

The entity that uses the metadata is supposed to validate the metadata in a "known good" way. This could, for example, be by only downloading it over a trusted channel (for example through HTTPS with normal certificate validation), or by storing a copy of the metadata locally having obtained and verified it in some other trusted manner.

In practice, metadata tends to also be XML signed, which provides an additional layer of integrity validation above and beyond the protection afforded by for example HTTPS. (This is a good thing particularly given how many implementations appear to require actually manually downloading and storing metadata in places where it could easily be modified, accidentally or maliciously. At least then the XML signature fails to validate, causing the metadata to be rejected rather than potentially incorrect metadata to be used.)

If you are unable to exchange SAML metadata while ensuring the integrity of said metadata, then you have a significant bootstrapping problem, to the point that I'm not even sure it's possible to use SAML in a secure manner. If you can't trust the certificate that is part of the metadata, that implies that you cannot trust anything else in the metadata either, including for example the endpoint URIs.

If you are able to exchange SAML metadata while ensuring its integrity, then by definition it contains a trusted certificate blob, which is intended (subject to restrictions stated in the metadata) to be used to:

Validate the signature on any incoming SAML data, including authentication requests and authentication responses, from the entity for which the metadata is generated
Serve as a recipient key for encrypted SAML data to the entity for which the metadata is generated (note that encrypted SAML XML is not supported by all implementations)

As that certificate (from the trusted metadata) is by definition trusted, using a CA-signed certificate provides no significant benefit over using a self-signed certificate. There is thus no reason to use a CA-signed certificate, and some reason not to (for example, on Internet2 it is recommended to use certificates with at least 10 years validity; I'm not aware of any commercial CA providing certificates with that long validity).

To mention but one admittedly somewhat anecdotal example, Microsoft's Active Directory Federation Services (ADFS) appears to be perfectly happy about self-signed certificates in SAML metadata; I have done on the SP side pretty much exactly the same that you have, in testing, with ADFS acting as the IdP.


Why aren't ransomware deployers arrested?

For the same reason for which other kinds of hackers aren't arrested. They may be trackable by the transactions. Unless they have a good system of money laundering. In addition there's usually the problem with international jurisdiction, etc, etc.

The bitcoin transactions may be run via hacked accounts and/or may be run over multiple accounts that are distributed over the world. There are thousands of ways to make money-streams (partially) untrackable. Bitcoin might only be a single station in the path of the money, till it finally reaches the distributor of the ransomware. This may be of interest, regarding the topic of money-laundering, as it (probably) describes a real-world case.

Next point:
It's just like with any other new field of illegal activity: arrest one person, two others pop up and take the place. The resources of police are restricted, the number of developers too high, etc... There actually are cases, where ransomware-devs are arrested (see Lukas's answer), but it's pretty tricky due to the points mentioned above and the number of ransomware software in the wild isn't likely to decrease, as long as there's no proper protection against it. As long as it's lucrative, there'll always be people who do it.

As @alexw already pointed out in his comment, the best way to protect yourself would be to regularly backup your data to an air-gapped system. The reason why ransomware still works is closely linked to the main-problem with this solution: it requires a user with a minimum of education on this topic, which is not the case with the average user.


Protecting bare text / link email address published in a website

There is not a thing you can do from the website in these circumstances.  Some basic modifications might help (only display it after solving a Captcha for instance), but it sounds like you don't want to do anything like that.  If your goal is to have it available as plain text on a page that is linked to from the main site, without making further changes, then it can obviously be found by spammers.
Honestly though, it doesn't really matter.  Spam is just a fact of life, and if your email address is something like info@exmaple.com, or support@example.com, it will get spam anyway because that is an obvious email on top of a public domain registration.
Other options
So what to do?  Just make sure you have a good spam blocker or use a provider that has strong anit-spam measures.  Educate yourself (and everyone else you work with) about the dangers of phishing and downloading attachments from people you don't know.  No matter what you do, you'll get spam anyway.


The setup can be considered secure. You do hold the decrypted data only in memory. Typically you will use a key per row to encrypt the sensitive data. However you cannot search for the data in the database (as you mentioned). It depends on the use case you may be able to solve the issue by hashing the sensitive data. When you want to search for a particular value you can hash the value before you search for it. However you can realize only a search for exact matches and not one with wild cards (the 'like' operator will not work!).

An entire different approach would be to encrypt the whole database. The data is stored encrypted on the hard drive. When you use AWS with RDS you can implement this strategy easily:
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html

All backups are encrypted and the data itself is also stored encrypted. However if someone access the database when it is running the data is not encrypted for this particular user. Means when you grant someone the permission to access the data it will be decrypted. However at the end it comes down anyway how you setup your IAM roles. Either you rely on the IAM roles for the KMS or for the RDS. So if setup the IAM roles properly you will be fine.
AWS supports since some weeks also the cross region replication of such encrypted database instances.

Normally for PCI DSS and for HIPAA compliance both approaches are accepted. As you looking for a way to search the data as well I would recommend the second approach.

Disk Encryption with RDS

RDS uses an EBS volume to store the data. The data on the EBS volume can be encrypted (see http://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html). Means when the RDS instance is accessing the EBS volume the data is encrypted resp. decrypted transparently. Means the read resp. write operation triggers a decryption resp. an encryption of the data.
You find here the details about how to setup RDS with encrypted EBS volumes:
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html
Essentially you have to specify during the creation of the instance whether it should be encrypted or not.

After you have setup this you need to setup a user with in the database which allows to access the database. Eventually you need also a IAM role which allows you to modify the database instance through your application. I don't know if you need the later. It really depends on your use case.

The last thing which I recommend is to encrypt the communication between your application and the RDS instance.

Summarized the data is never stored unencrypted. The data is always decrypted when it is used and the unencrypted data is only kept in the memory (RAM).


Why can't apple simply add the backdoor now and then remove it after the FBI is done?

The whole story is weird. Since the iPhone in question does not have a tamper-resistant device, the FBI should be able to open the case, read the whole Flash chip, and then run the exhaustive search themselves without even running the phone's firmware. Updates from Apple should have no effect at all.

(Edit: in fact it is a bit more complex; see below.)

Conversely, assuming that there was a technical impossibility in the description above (which would amount to claim that the FBI's level of incompetence is at least as large as their budget), and that an Apple firmware would solve the case, then it would be easy for Apple to make a firmware version that does the exhaustive search as the FBI wants, but only after having checked that the hardware serial number exactly matches some expected value, i.e. the exact phone from the San Bernardino case. Such a firmware would comply with the exact demand from the FBI without compromising the privacy of anybody else.

That the FBI claims to have tried decrypting the phone for one month and failed, is weird. That Apple refuses to help with the decryption with a firmware update limited to a single phone, is equally weird. What the whole thing seems to be is a political struggle about the right to privacy and the legality of non-judicial eavesdropping by law enforcement. The San Bernardino case is merely a pretext that is used to elicit reflex support from non-technical electorate. Apple found it expedient to play the role of the White Knight, from which they cannot now back away without alienating their consumer base.

Edit: the security system in an iPhone is a tower of elements, described (succinctly) in this document. An iPhone 5C runs on an Apple A6 chip, which the 5S and later models use an A7. The A6 has an onboard tamper-resistant device called the "UID"; the A7 has a second one called the "Secure Enclave". Since the iPhone in the San Bernardino case is a 5C, I won't talk any more of the Secure Enclave.

The UID contains an internal key that is unique to the device (let's call it Ku), and is unknown to anybody else, including Apple (whether the UID generates it itself, or it is generated externally and then injected in the UID on the processing chain, is unknown; I'll assume here that if reality matches the latter case, then Apple really did not keep the key). The UID never let that key out, but it can do an AES-based computation that uses that key.

The iPhone data is encrypted with AES, using a 256-bit key (Kd) that is derived from the combination of the user PIN and the UID key. Though Apple does not exactly detail that combination, it says it involves key wrapping, which is another name for encrypting a key with another key. We also know that a user can change his PIN, and it would be impractical to change the actual data encryption key Kd in that case, because it would involve reading, decrypting, re-encrypting and rewriting the gigabytes of user data. Thus, a plausible mechanism is the following:

The key Kd has been generated once.
When the phone is off, what is stored (in Flash, out of the UID) is an encryption of Kd by another key Kz.
Kz is itself the encrypting (wrapping) of the user PIN by Ku.

Thus, the unlocking entails obtaining the user PIN, submitting it to the UID, who returns Kz by encrypting the PIN with Ku. With Kz, the phone's firmware then recovers and decrypts Kd, and configures the crypto engine to use that key for all accesses to the user data.

While the actual scheme may differ in its details, the general outline must match that description. The salient point are that, although the tamper-resistant device (the UID) must be involved with each PIN try, it does not actually verify the PIN. The UID has no idea whether the PIN was correct or not. The wrong PIN counter, the delay on error, and the automatic deletion, are handled externally, by the firmware. This must be so because otherwise there would be no sense in Apple allowing the break to be performed with a firmware update.

Of course, one can imagine a kind of extended UID that would enforce the PIN verification and lock-out strategy, and could do so by running its own firmware that would be updatable by Apple. Such a device would really make Apple's help crucial. However, such a device would then be called a "Secure Enclave" because that's exactly what it is, and if it was added in the A7 CPU, it is precisely because it was lacking in the A6 and that absence was a vulnerability.

So what does it mean for a brute-force attack ? This implies that the UID must be invoked for each user PIN try. However, that's the UID -- not the phone's firmware. If you open the iPhone case, then the A6 CPU sub-packaging, the device UID can be accessed by connecting to it directly. It will involve some precision laser-based drilling and an electronic microscope to see what you are doing, so it certainly is not easy -- let's say it will cost a few thousands of dollars because that's the same kind of thing that is done (routinely !) by people who clone and resell satellite-TV access smart cards. Once connected, an external system can submit all possible user PIN for the UID to encrypt them all and provide the corresponding Kz keys (in my terminology above). Then the rest is done offline with a PC and a copy of the Flash storage. At no point is the phone's firmware invoked.

What the FBI currently asks for is an automatization of the process. They don't want to do precision drilling with lasers. They want to be able to plug something in the iPhone port without having to even open the case, so that the brute-forcing is done by the iPhone's CPU itself and the whole process can be done smoothly.

Thus, it is really not about the San Bernardino case. The FBI does not want a one-shot intervention from Apple; what they ask for is a tool that will be usable repeatedly on many phones. Apple is right in claiming that what the FBI asks for exceeds the specific case that serves as emotional pretext.

On the other hand, Apple could produce a firmware update that does as the FBI asks for, but only on the specific iPhone (identified through, for instance, the CPU serial number). And that firmware update would be specific to the 5C, and would not work on later models. There is no inevitability in Apple's producing a new firmware leading to a generic cracking tool for all phones of all models. But even if Apple complies with the a firmware that is specific to a single iPhone, the legal precedent will have been established, and Apple would find it hard to refuse other requests, from the FBI or from other countries where Apple has business interests (i.e. all of them).

A system which would ensure protection against user PIN cracking would need a tamper-resistant device that not only enforces the PIN failure counter and key erasure, but that device should also run a firmware that is not upgradable. The Secure Enclave has its own firmware, but it can be upgraded (firmware upgrades are signed by Apple, the Secure Enclave hardware verifies the signature). Even on an iPhone 6, Apple retains the ability to unlock arbitrary phones.


DNS resolution attacks by flooding spoofed replies

This sounds like a component of a broader targeted attack involving spear phishing.  You might send a link to the victim for Banking.Example.com and begin your DNS reply spam for that domain.  That way, you know which domain they are trying to resolve with DNS.


Passing arguments to NSE script is very easy once understood properly. Basically it follows the format of lua table. Also, if you get any doubt with your Nmap's options usage you can turn on debug mode using -d<level> flag. Usually -d2 is sufficient for looking at scripts. For the given script http-default-accounts it would be like -

nmap <options> --script http-default-accounts --script-args "http-default-accounts.basepath='/admin', category='web', fingerprintfile=/usr/share/nmap/nselib/data/http-default-accounts-fingerprints.lua"

Notice that I've used script-name.argument format as well as argument format in the arguments. Both of them work same while former is used when different scripts assume same argument variables and you want to give different values.
In the current state, this script does not take multiple basepath or category or fingerprintfile. To master the script argument usage, you can try using the http-form-fuzzer script which can take up nested table of any depth.


If an HTTP request is capable of changing state, then it may need CSRF protection. Whether or not the request is encrypted at the transport layer has little to no relation to this.
Without CSRF protection, an attacker who convinces you to visit their website or even a single resource may be able to send requests to your embedded device and take control over it, if the victim's browser is properly authorized or there is insufficient or broken authentication. This happens regardless of whether HTTP or HTTPS are used.
Yes, ideally everything would be over HTTPS. However, the "best" option for most vendors right now is to ship embedded devices with self-signed certs which, other than being good for trust-on-first-use and thwarting passive sniffing, are not much better than plain HTTP in many scenarios. Often, the user will still get a certificate warning and click through it. Until this problem is solved, the HTTPS outlook on embedded devices is still dismal.
(Addressing your now-deleted edits) Indeed, XSS bypasses CSRF mitigations. However, the threat model seems a bit different here, since its way less likely for an adversary to be able to exploit an XSS in your embedded device than a CSRF issue, since they would have to get to the device in the first case.


Best resources to learn web security attacks?

OWASP has a couple of very interesting resources of this kind:

Hacme Bank: a banking application built with some vulnerabilities for you to find and try to exploit
The WebGoat Project: web application with several vulnerabilities. Every possible attack is explained in a specific lesson, so that you can concentrate on one technique at the time


Yes, you can unlock and use the device even on Windows 10 Home edition. However, you won't be able to manage the BitLocker.

Also, BitLocker is a part of Windows and is installed on every Windows copy by default.

Whether is it in compatible mode or not is not important in this case (Home/Pro). That would be important if you use older versions of Windows 10 or even older versions of Windows (8.1, 7, ...)


Is it possible to forge post request and bypass maxlength in input box?

Yes. It is possible. Maxlenght is a html attribute in client browser's DOM object.

Maxlenght is significant only in the client browser, it is not significant on server side unless you code the server side to validate input length.

If you are using a intercept proxy which doesn't create DOM object can easily bypass the Maxlength or any other parameter and javascripts too.

Bypass can be done via a different domain/web page with different html attribute that does not put any restrictions on input length to cause XSS.

Sounds like the type of XSS you are attempting is a server side Non-Persistent XSS flaw -
User input consists of malicious code that get returned in server's response to the request, it doesn't get stored in the web app so it is specific to that request.

I think you need to improve the javascript you are using to exploit XSS. onmouseover="alert(0)" cannot exploit XSS, it is just a DOM based local action to client browser, onmouseover will not send the input to the server to get returned back to the client. Your javascript must be sent to http://www.site.rs/usersearch.php and returned back by the server.


Where can I find information about how to implement Intel embedded AES256 encryption?

The AES instruction set is supported by most modern compilers (gcc/g++ 4.4 or later, Visual Studio 2008 SP1 or later, Intel c/c++ compiler 11.1 or later).

For gcc, you'll have to use the -mtune with a supported CPU type, or the -maes switch.

It looks like the next generation Cryptography API for Windows (in Windows 7) supports AES-NI. So, if you are using the Crypto API in your code, that should automatically happen on supported machines.

Your other option is to use a precompiled library that has AES-NI support built in. Wikipedia has a list of libraries.


You can use the following content types without CORS access:

application/x-www-form-urlencoded
multipart/form-data
text/plain

You can try a couple of things:

Try sending valid JSON with another content type. Some implementations don't look at the content type.
Try sending valid form data with the correct content type. Some implementations accept multiple ways to send the data.

If the application really needs the application/json content type, it is not possible to send a cross-origin request.


Is corrupting the ciphertext corruption a good erasure?

Normally when you wipe a drive there are still ghost remains of the data even after overwriting the disk multiple times.

I'll save you some work. This isn't true, and hasn't ever been true as far as anyone can tell.

The technique often referred to here is called Magnetic Force Microscopy (MFM) and was referenced in an old DoD standard for disk erasure. Despite attempts to replicate the concept, nobody has ever been able to recover data from a magnetic disk erased with even one pass of random data, and nobody has ever been able to recover data from a magnetic disk erased with one pass of zeroes outside of lab conditions on very old low density disks (5GB in size or less). It is estimated that those processes could only be performed at a rate of megabytes per month on disks erased with a zero wipe pass, and without complete confidence in the resulting data (bits could be wrong!).

Modern disks have such a high density that overwriting with random data destroys any chance of reading any "latent" magnetic data, even with sophisticated specialised equipment. The physics just doesn't work that way. The signal to noise ratio between the newly written data and whatever "latent" magnetic trace is so vast that there's no way to recover a "previous" bit's value with a confidence better than 50-50.

MFM and similar myths are often touted by disk erasure software companies who want to scare you into thinking you need their product. You can particularly ignore anyone that references the Gutmann method, which was designed for types of magnetic disks from the 80s and 90s.

Current DoD guidelines for disposal of magnetic media state that a single random data pass is sufficient up to SECRET, and physical destruction is advised for TOP SECRET. The latter is most likely a risk assessment that it is probably cheaper to destroy the disks completely rather than risk the potential of getting something wrong during the wiping process. Anything in excess of a single random wipe pass is pure superstition. All you're doing is wearing out your disk.

For SSDs, you'll want to use ATA Secure Erase. The implementation of this is vendor specific so you'll want to find the tool from your SSD manufacturer that lets you do it. There are some generic ones that try to cover off most SSDs too. The way it works is that all modern SSDs (barring some very early ones) generate a random encryption key during first initialisation, and then transparently encrypt all data on the SSD after this. This includes data written to otherwise inaccessible sectors provisioned for wear-levelling and other SSD operations. As SSDs have limited write cycles, it isn't very efficient to overwrite every sector with random data or zeroes. Instead, ATA Secure Erase simply resets the encryption key on the disk to a new random value, thus rendering all previous data on the disk unreadable. This negates the need for a costly wipe process, with the added bonus of being very fast.


Saving encrypted username password in session

From strictly a security standpoint, you can do it this way, but it is not ideal. Even though the credentials are only stored temporarily on the server (and perhaps configured to only be stored in memory too), the fact that they are there longer than they potentially need to be poses a risk, albeit a small one. Note that encrypting the credentials in session probably doesn't help you that much, since your key to decrypt must be accessible by the server. In order for someone to read unencrypted session they would need to gain control of the server, and if they did that they could read an encrypted session too, so encrypting it just makes it slightly more annoying for the attacker to get to it. That being said, I would prefer one of these options:

If both the web application and rest applications are using the same LDAP credentials, then there should be a way to configure the rest apps such that they can share the same token the web app is using to authenticate the user with each request. If you can accomplish that you would not need to store anything in session, since the web app could pass on the token it received with each request.
A simpler approach would be for your web server to have it's own set of (admin-like) credentials to access the rest applications, and it would authenticate on its own independently to gather data it needs for the user, perhaps by querying by a particular user id. Of course this assumes the rest services are able to provide this functionality.


Is signing android apk file with SHA1 digest secure enough?

MD5 and SHA-1 have flaws with regards to collisions (in the case of SHA-1, these flaws are "theoretical" in that no actual collision has been produced yet). Collisions are not necessarily a problem, depending on the context.

A collision is a pair of inputs m and m' that are distinct, but hash to the same value. Since signature algorithms operate on hashed messages, a signature on the first message of a collision pair would also be valid for the other message, mechanically. Collisions are distinct from second preimages in the following sense:

in a second preimage, the attacker is shown a message m and is challenged with finding a distinct m' that collides with m;
in a collision, the attacker chooses both m and m'.

Currently, there is no known second preimage attack on SHA-1 and only a very very theoretical second preimage attack on MD5 (effort of more than 2120).

App signing is about accountability. Normally you would not want to install an app that may do bad things; the signature does not guarantee that the app does not do bad things, but it gives the user retaliation power: the signer should not be able to deny having signed the app. This is important to remember: the signature does its job as long as it allows tracing back to the culprit.

An attacker might want to make two versions of his app, the two versions hashing to the same value, and thus using the same signature value. One version would be "honest", and the other would hijack your phone or enact similar naughtiness. But what it would gain to the attacker? If application m and application m' share the same signature value, then the signature "proves" that the author of the application really wrote both... which is entirely true! The security property of the signature, the accountability, is still valid in the presence of collisions.

What the attacker really wants is a second preimage: he wants to make a bad app which is signed by somebody else. For that, he needs to take an existing "honest" app, and make a new one that hashes to the same value, thereby allowing him to borrow the signature value. Right now, nobody knows how to do that with a RSA/SHA-1 signature (or, for that matter, with a RSA/MD5 signature).

Collisions can be a problem when the attacker gets to choose what will be signed by somebody else. This is what happened with a demonstration involving RSA/MD5 and certificates. This, however, does not apply to your context, when what you sign is your own app. Collisions on MD5 or SHA-1 would be relevant if we imagined a situation that would go thus:

Attacker makes a pair of apps, an honest one, and a malicious one, that hash to the same value.
Attacker submits the first app to someone who can sign app.
The signer inspects the app code thoroughly, sees that everything looks fine in it, and signs it.
The attacker then reuses the signature value on his malicious app.

Even in that case, while the signature would point at the signer, that signer would know, in case of trouble, that the malicious app is not what he signed. In fact, he would simply exhume the "honest app" from his emails, show that both the honest and malicious app are a colliding pair for the hash function, thereby demonstrating the malicious intent of the app author (you don't get collisions out of bad luck; you have to do it on purpose).

Summary: known flaws of MD5 and SHA-1 with regards to collisions do not endanger the security model of app signing. It still is a nice idea to investigate usage of more modern and robust functions such as SHA-256, but there is no urgency.


What are the security issues of open ports?

An open port is an attack surface.  The daemon that is listing on a port,  could be vulnerable to a buffer overflow,  or another remotely exploitable vulnerability.

An important principle in security is reducing your attack surface, and ensure that servers have the minimum number of exposed services.


From the Sulley manual,  it is the

Encoding to use for string

I think that's your second case.


The actual user table (Note: singular) you are looking for is in the mysql db not the users db (Note: plural). The users database you are referring to is probably something you (or DVWA, or whatever you're practicing with created). If you want the MYSQL users (and hashes), you'll need to get to the database engine's configuration tables, specifically: user.

REFERENCE

https://dev.mysql.com/doc/refman/5.5/en/password-hashing.html


Are we obliged to provide a complete log should auditors ask for it?

This depends on the type of the audit and the contract between your company and the auditing company. Furthermore privacy laws, agreements concerning privacy related data and NDAs may play an important role in judging the request.

As a practical advice: Ask your legal department as this is not a question rooted in IT but in laws and contracts. Try to explain your concerns in a way that is understandable to lawyers with little IT background.

You can try to provide a stripped down log as initial response and ask the auditor to clarify if additional data is needed and why. But whether this approach is a good idea or not, depends on the situation.


Is malware programmed in high-level language will be more detected than malware programmed in low-level language?

What the processor sees when it is executing is never the source code - it sees machine code, which in its human-readable format is called assembly code.

When you compile a program, in any compiled language (more on that later), the compiler takes the high level code, performs operations on it, links it all together and turns all of that into machine readable code.

Here is an example of Assembly for x86 "Hello World" (DOS) [Robert Montante, Bloomsburg University]

    org  0x100        ; .com files always start 256 bytes into the segment

    ; int 21h is going to want...

    mov  dx, msg      ; the address of or message in dx
    mov  ah, 9        ; ah=9 - "print string" sub-function
    int  0x21         ; call dos services

    mov  ah, 0x4c     ; "terminate program" sub-function
    int  0x21         ; call dos services

    msg  db 'Hello, World!', 0x0d, 0x0a, '$'   ; $-terminated message

This machine code we compiled only works for one architecture, and on that operating system. This is why we often need different binaries for x64, x86, Linux, Windows, OS X, etc.

This, however, is very annoying - having to recompile 6 different binaries for each version is tedious. This changed with the popularity of Java and the JVM (Java Virtual Machine) that ran it. Instead of compiling down to processor-level machine code, the programmer didn't have to do any machine code compiling - they only had to compile it to an intermediary "byte-code" which was then interpreted by the Java Virtual Machine.

This meant that, as long as you had the Java Virtual Machine installed, you could run any Java Application on your computer, even if it wasn't written for your computer. This does have its own problems though.

Anyway, to answer your question, with this background information. When Anti-Virus solutions "scan" they're normally just doing signature analysis. This is where the files and/or their components are compared to a big database of known malware signatures, analysed by the security researchers and computers at the AV company. This is why it's important to keep your Anti Virus up to date, because these new threats emerge all the time. However, it also means that, in general, there is no benefit to any specific language, or choice of abstraction level, for avoiding detection. Malware detection is typically mitigated during / post compilation by the malware creators, not during.

An exception, possibly, is Assembly Language. Some droppers (Small malware that installs other malware), are written in assembly language to make them difficult to detect, or automatically rebuilt themselves with randomisation to avoid signature matches. However the drawback to writing malware in assembly is it takes a long time and is very difficult.


My postfix server is getting DOSed, what can I do?

If you can, try to :

Rate limit your router to prevent your server from being
overwhelmed
Add filters to tell your router to drop packets from the obvious
sources of the attack
Timeout half-open connections more aggressively
Drop spoofed or malformed packets
Set lower SYN, ICMP, and UDP flood drop thresholds


How do I scan for and discover active IPv6 addresses of devices behind a router?

You can't, as there are too many addresses to scan for. Typically a residential ISP will assign a /64 subnet per customer, which means there are 18446744073709551616 possible addresses behind that router. That is a lot of IPs to scan.

Also, the fact that IPv6 addresses are publicly routable doesn't mean the router can't get in the way and firewall off your scanning attempts. While most consumer-grade routers are crap and don't support that, it is quite easy to configure with any decent Linux distribution. I assume business-grade routers such as Cisco also support it.


Reporting SQL injection vulnerability to company that does not care

Check out how Secunia deal with it. Might help you along:

http://secunia.com/community/research/policy/

If no security contact is known for the vendor, an e-mail requesting the security contact e-mail address may initially be sent to certain public e-mail addresses associated with the vendor. It is Secunia policy to never submit vulnerability information via online forms. However, these may be used to request security contact information.

When a security contact or other relevant e-mail address has been identified, a vendor initially receives a mail with vulnerability details along with a preset disclosure date (usually set to a Wednesday two weeks later).

If the vendor does not respond to the initial mail within a week, it is resent.

If no response has been received at the day of the preset disclosure date, the vulnerability information is published immediately without further coordination attempts.

If the vendor responds to either the initial mail or the resent mail, a new disclosure date may be set in case the vendor cannot meet the preset date.

Secunia expects vendors to provide continuous status updates on the progress. If none are provided by default, the vendor will be contacted about once a month with a status update request.

Should a vendor not respond to a status update request, it is resent a week later.

Should the vendor not respond to two consecutive status update requests, a mail is sent to the vendor advising that the vulnerability information will be disclosed a week later if no response is received. Has no response been received by this date, the vulnerability information is immediately published without further coordination attempts.

Eventually, the vulnerability information will be published by Secunia Research when:

a) The preset/agreed disclosure date is reached.

b) The vendor issues a fix and/or security advisory.

c) Information about the same vulnerability is published by a third party.

d) Either a half or full year has passed from the initial contact date (see #10 and #11 for more information).

By default, vulnerabilities are coordinated for no more than 6 months. About one month prior to the ½ year mark, the vendor is informed about a fixed disclosure date set by Secunia Research at the ½ year mark. At that time, a Secunia advisory is published regardless of patch availability.

A vulnerability may in certain cases be coordinated for up to one full year if the vendor is communicating a clear intention to address the vulnerability and can commit to a date within that period and the vulnerability is considered to be complex to address.


Rate limiting is probably the only practical way to mitigate these attacks for most public-facing applications. And you're correct in that it's a security/UX tradeoff.

Given the login form example alone, "your username or password is invalid" is a more secure (exposes less information) way to present info, but most public services have other endpoints to check for usernames anyway.

The attacker can, for example:

check for a "user profile url" if implemented in the app (eg. /users/profile/NAME)
or hit the "create a new account" endpoint and get "username/email exists" info from there.
or create a new account and hit a (for example) "send a message to user NAME" and get info from that response.
etc, etc

If you add rate limiting then these attacks will take a lot longer (to the point of being impractical — depending on your user base size and rate limiting details), but in theory it's still almost always possible.

It's possible to leak zero information about accounts, but that will make the experience for actual users much more confusing.

Imagine an existing user tries to create a new account — you have to accept all the info, show an "Account created" page, detect it's a duplicate, and email the user that "you tried to create an account, but already had one".


It is possible to access the database with XSS,  if an attacker delivers an XSS payload to a browser that has database access.  XSS allows an attacker to control a browser,  if that browser is an authenticated user then an attacker can carry out actions as that authenticated user.


What are the traces of a mysql attack on a server when the attacker has full permissions?

Depending on the privileges the mysql user (the system-level account used to run MySQL) has and how MySQL is configured, the traces could be anything from a full audit trail in the MySQL log files, to no trace whatsoever.

Assuming the mysql user can't do anything but read and write files, your bet bet is to search the drive for files owned by that user.  MySQL doesn't normally create files outside its data directory, so anything you find outside of there is suspicious.


Can password_verify() be used to identify password after database breach?

password_verify() takes two arguments: a string of which you want to check if it's the correct password, and the value you calculated earlier with password_hash(), which you presumably stored somewhere in a database or so.

A typical application could be:

<?php
$hash = password_hash('my-secret', PASSWORD_DEFAULT);
// normally you would save the hash somewhere, but we'll just continue in this example

$check_a = 'other-secret';
$check_b = 'my-secret';
if (password_verify($check_a, $hash))
   echo 'Check A was the original password: ' . $check_a;
if (password_verify($check_b, $hash))
   echo 'Check B was the original password: ' . $check_b;

The output will be:

Check B was the original password: my-secret

If you want to get the original password from a hash calculated by password_hash(), you'll need to try all possibilities - that's what this example shows. Because of the architecture of password_hash(), finding a password like this will take a long time, so it's not worth it.

Note also, from the password_hash() doc:

  PASSWORD_DEFAULT - Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP. For that reason, the length of the result from using this identifier can change over time. Therefore, it is recommended to store the result in a database column that can expand beyond 60 characters (255 characters would be a good choice).

The algorithm is designed to change over time, so that it stays secure, and finding a password by brute force won't become possible with faster computers (presuming, the PHP installation on your server is up to date)

In any case, a hash is one-way: you can't turn it around. You can only verify a given password by computing the hash of that one, and checking if it's the same.


Password Managers: encrypted database vs hashing strategy

As @CodesInChaos comments, an encrypted database, if done properly, will be at least as strong against brute-force attacks as a hash value. From that point of view, the hash-based method is not more secure. There are details, though, depending on the attack model:

With the local database of passwords, you can use random site-specific passwords. If one site is hostile, then it may learn your password for that site, but this will get him nowhere because there is no actual mathematical relationship between the master password (for database encryption) and the password you show to the sites. On the other hand, you have a local database which you must store somewhere (e.g. in your laptop computer), and if an attacker steals that storage then he can try an offline dictionary attack (i.e. brute force on your master password).
With the hash-based method, there is no database at all, hence the laptop theft scenario no longer threatens the confidentiality of your passwords. For that specific attack model, the hash-based method is superior. However, it also implies that each site-specific password can be used for an offline dictionary attack on the master password. So that's the trade-off: you are depriving the local thief from means to attack your master password, but you are giving such means to every site you register in.

If your master password is strong enough (say 80 bits of entropy or more; less might be sufficient is proper password hashing is used), then dictionary attacks don't work, and both methods have equivalent security (i.e. "not breakable through brute force").

If your master password is not strong enough, then I'll tend to prefer the database method, because ensuring physical security of a single laptop looks easier than ensuring that every single site I use is honest, competent, and not under hostile control.

As for usability, one may note that the hash-based method has the following issues:

You get only one password per target site. If the site wishes to force a password reset, and filters out attempts at reusing the same password, then you lose.
All sites don't have uniform requirements. In fact there is no password which could be used on every site, because length and contents requirements used in practice are not compatible. For instance, some sites mandate a minimum password size of 10 characters, while others mandate a maximum password size of 8 characters; there also are conflicting requirements on use of punctuation signs, digits,...

Both issues are easily solved by keeping track of site-specific password requirements, and possibly a site-specific counter or salt value to handle resets. But that means a "database", which voids the usability advantage of the hash-based method. That database contains only public data so it needs not be encrypted, but that's all.


texting password reset link instead of a code

I can think of a couple of flaws with that plan:

It doesn't work for users who are using a different device to perform the password reset for some reason, such as not using a smartphone. For Facebook and Google, it's not uncommon for users to change their passwords using a computer, but to receive a validation code by mobile.
Potentially increases the risk of phishing attacks, by encouraging users to follow shortened URLs claiming to be from a service provider. The use of bitly adds to this, since it's not easy to see the URL which the link actually goes to.

For a mobile application, it's a flawed premise to begin with though, since SMS is not a second factor in this case (an attacker with the phone has access to the SMS message!). Some providers take this into account, and require that password changes are performed through the website, even when they have an application, in an effort to ensure that the existing password is known to the person attempting to change the password (requiring that it is entered for password changes would also work, of course).


Combinations of key exchange and signature algorithm in TLS

In order to have high encryption strength, one would use large DH params (16k perhaps) since the classical DHE key exchange is not computationally expensive,

I can't give you hard numbers for the speed. The openssl speed command does not seem to offer the benchmark for regular (finite field) Diffie-Hellman.

This answer offers guidance on practical DH-parameter sizes:

Thomas Pornin. Answer to: Is this prime number large enough / too large for a Diffie-Hellman for AES-256?

  this combination is not part of the TLS specification (as far as I know)

Correct. There is no combination of _DHE_ and _ECDSA in the current cipher suite assignments.

$ wget https://www.iana.org/assignments/tls-parameters/tls-parameters.txt
$ cat tls-parameters.txt | grep -i _ecdsa_  | awk '{print $2}' | cut -d _ -f2 | sort | uniq -c
     17 ECDH
     21 ECDHE


Is there a way to protect a supporting app against changing the REST endpoint?

Now, assuming I fill the gaps and will be able to successfully buy stuff

That's a pretty big assumption. But if the app does have enough information locally to command a vending machine to dispense product, this suggests that the vending machine may not be performing any complex validation locally, and that the mobile phone has been left in charge of security. (Or that the vending machine is only validating the presence of the mobile app, not the involvement of the server.) If so, this may be hard to fix.

A reasonable security architecture for an application like this would run along the lines of:

The vending machine generates a nonce which includes its serial number and some random data, referred to as the "token".
The mobile phone retrieves this token from the vending machine and passes it on to the web server, possibly along with other data like payment information.
The web server verifies that the user has paid, then signs the challenge with its private key and returns it to the mobile phone.
The mobile phone passes the signed token on to the vending machine.
The vending machine verifies the signature on the token using the server's public key (which it has stored internally), verifies that it has not seen the token before, then dispenses product.

Since the vending machine will not accept a token which isn't signed with the server's private key, and it will not accept a token that came from another machine or which was already used on the same machine, there's no way to get it to dispense product without going through the intended workflow.

(The use of a nonce is required to prevent a user from reusing a token which was previously used, either for the same machine or another one.)


Does using Ghostery with Privacy Badger impair PB's heuristic learning?

Yes and no - the sites blocked by ghostery (or other ad/tracker blockers like uBlock or Disconnect) won't be picked up by Privacy Badger, meaning that they won't get included in its heuristics. At the same time this means that they are successfully getting blocked - by your other ad/tracker blocker.

This means that Privacy Badger will catch all the things that don't trigger the block lists on your ad blockers. If you turn off your ad blocker then there will suddenly be new third parties that Privacy Badger hasn't seen before and it will take it a few visits to flag these as trackers. But if you use the same ad/tracker blocker regularly you shouldn't have this problem.


Is it possible to hack a SSID without actually having to sniff or send deauth frames to a host?

If the network is WPA2 as you sais in comments, this is what you can do:

You didn't specify if there is WPS enabled or not. So check that using wash (included on reaver package) or using --wps on airodump-ng. Then if enable you can try Pixie Dust attack (very fast but only affecting some Access Points, maybe you could be lucky). Also you can try bruteforce on PIN or an attack based on a PIN database.
Another way to hack it is getting a Handshake and then cracking it offline. To do that, you must be "listening" with airodump-ng while a legitimate client connect to the network. It doesn't matter if the SSID is hidden. You'll get the handshake anyway and you'll crack it offline based on BSSID. To obtain it, the common method is using DoS deauthenticating client but your question said "without send deauth frames". So if you want the Handshake without DoS you only can wait, wait and wait... until a client connect to get it. You sais there is no clients connected to the network. Maybe you can only set the "listening" and wait for days... Once you have the Handshake captured file you can crack it without fear of being detected or whatever, is an offline proccess. You can use aircrack or hashcat tools (or maybe other).
Another possibility is to create a Rogue AP Evil Twin with a captive portal hoping the victim confuse the network and put his/her wireless password on your trap. This attack requires a little bit of "social engineering" and a victim without any knowledge about networking (but believe me sometimes it works!). Is usual again to perform DoS to the legitimate network to force them to investigate and maybe they can make click on your fake network. Again without sending "deauth frames" is very very difficult to be successful with this kind of attack.

Of couse you can perform all of these actions with your MAC spoofed to be pretty sure of you are not being detected.

I'll recommend to you a tool what can do ALL of these attacks: airgeddon

Hope it helps!


Does EMV protect against sniffing PAN data from untrusted network?

Many people are surprised to learn that EMV doesn't encrypt the PAN.  But really, once EMV is fully rolled out encrypting the PAN will become unnecessary, and would be leftover as a technical debt of the current insecure protocols.  EMV doesn't need to start with that baggage.

The reason EMV doesn't require encryption of the PAN is that the PAN only represents Identity; it does not represent Authentication of the chip (that's the job of the ARQC message), and it does not represent the Authorization of the cardholder to use the card (that's the job of the PIN).  As long as the chip is authenticated, and the user provides the authorization, the transaction is secured.  The identity doesn't have to be kept secret.

In today's non-EMV world, identity, authentication, and authorization are all three combined on the unchanging mag stripe.  Copying the stripe data enables you to clone a card, so protecting the whole stripe is required.  We use the words "identity theft" so people think they're stealing our identity, but really, they're stealing all three attributes from the card at the same time.

With EMV, the PAN is still required to provide the identity of the card.  The rest of the EMV data does not include enough information to otherwise identify the card, nor should it.  The identity can even be made public, as long as it can't be used by itself.

In EMV, the ARQC cryptogram serves as the signature from the chip, authenticating the messages originated from the chip associated with the PAN.  Cryptography and secure storage on the chips ensure that an ARQC can't be forged.  Because the ARQC is transactional, every request is different; replay attacks don't work as long as the bank ensures duplicate ARQCs are rejected.

The PIN serves as the user's authorization to charge.  The PIN tells the chip "hey, your user just proved right now that he wants this transaction to go through."  It's up to your bank if they want your card to require a PIN; they might be happy just letting you sign for the transaction.

[ Note that most U.S. banks opted for Chip and Signature instead of Chip and PIN.  The only advantage of Chip and PIN is that it protects your card from unauthorized use if it's lost or stolen; but really, the FDIC already limits your personal liability to $50, and almost all banks waive that to $0 in the case of a lost or stolen card.  And since the banks make money every time you charge anything, they'd rather accept the risk of fraud (that they're already obliged to take by law) than to inconvenience their customers by making them type a PIN.  They believe that inconvenienced customers will find an easier way to pay, cutting into their profits.]

But we're a long ways away from full EMV rollout.  The October 2015 liability shift was created as incentive for U.S. retailers to change their transaction processing to use EMV, but very few U.S. retailers actually take chip cards as of April 2016.  Rolling out new terminals, new software, and new cards across 6 million retailers, 11,000 banks, and billions of cards takes a lot of time and money.  And nobody's yet created a universally accepted solution to secure Card Not Present (CNP) transactions, such as hotel bookings, web purchases, etc.  So until EMV is fully deployed and the CNP problem solved, it's still up to merchants and POS terminals to protect and encrypt the PANs and the sensitive authorization data.  For now, that includes the PAN.


Is BSI’s process good? (Informing email address owners that their address/password (of unknown/different accounts) was stolen)

I think this is a matter of degree. The list will help many people but maybe not everyone. However, if someone already has control of your email you have bigger problems anyway.

It is better than not being able to find out at all though as at least the majority of people will be able to find out and change their details if needed.

The only improvement I can think of would be to have a pre-confirmation first. You put in your address, the system sends you an email with a code you haven't seen. You enter the code and that confirms that you have some level of control of your email address. Then it sends the information. Any hacked account would then need more sophisticated monitoring and filtering to let through the first email but not the second. Hardly worth it for anyone to do.


samdump2 Error reading ControlSet: _RegOpenKey

well i got it to work by following theses steps :

You have first to install a compatible version of samdupm2 and bkhive (because I have tested the ones on the repositories and it doesn't work well) using this commands :

curl http://http.us.debian.org/debian/pool/main/s/samdump2/samdump2_1.1.1-1.1_i386.deb > samdump2_1.1.1-1.1_i386.deb

dpkg -i samdump2_1.1.1-1.1_i386.deb

curl http://http.us.debian.org/debian/pool/main/b/bkhive/bkhive_1.1.1-1_i386.deb > bkhive_1.1.1-1_i386.deb

dpkg -i bkhive_1.1.1-1_i386.deb

Ps : If you have problems with dependecies then execute this command sudo apt-get install -f
Then you have to use bkhive on the SYSTEM file with this command bkhive SYSTEM keys.txt.
And finally we use the samdump2 to get the hashed passwords using this command samdump2 SAM keys.txt > hashed_passwords.txt.

I have just tested it and it works just fine.


Retina tells me I do not have permission to scan a range. I have full permissions. Why?

Reading the fine manual, I found this tidbit about permissions:

  Manual Range Entry
  Allows the user to manually enter ranges for Scans
  and Deployments rather than being restricted to Smart Groups. The
  specified ranges must be within the selected Smart Group.

[Emphasis mine]

On a hunch, I tried this:

Go back to the Assets tab
Choose "All Assets"
Try running my scan again, manually specifying a range like I did the first time.

And it worked!

The problem is that retina still confines your scan to the Smart Group you chose in the Assets tab even when you choose to scan a single IP address or IP Range.

In summary:

To avoid a permissions problem when manually entering an IP or IP range to scan, first choose the All Assets Smart Group.


Generating another public-private key would be overkill for this senario.

If you're really worried about some malware reading the browser cache, you can instruct the browser to just not cache anything.

<meta http-equiv=”Cache-Control” content=”no-cache” />
<meta http-equiv=”Cache-Control” content=”no-store” />

If you're worried about someone reading through the memory to find the plaintext of the username and/or password then you can implement at a solution similar to the one defined in senario #2 here (http://resources.infosecinstitute.com/browser-based-vulnerabilities-in-web-applications/)

Note that you have to scroll down a bit on that page to see the content, there's a giant ad that pops up first.


Is there a difference between editing HTTP messages manually or with burp for example? (WebGoat HTTP intercept exercise "problem")

I'm assuming you mean "use Burp's built-in functionality, such as Change request method", when you say "editing HTTP... with burp" (as opposed to "manually"), and that just changing the request text in the edit box is the "manually" you mean. If that's wrong, please clarify.

Burp does a number of things quietly and automatically, which you might not realize. Among them:

Updating the Content-Length header if you edit the body.
Removing Content-Length and Content-Type if you use its built-in feature to transform a POST request into GET, and vice-versa.
Decompressing and/or stitching together requests and responses that are sent compressed / chunked.

There are some things it does not do (by default), though:

Ensuring there are two newlines at the end of an edited request.
Ensuring newlines are in the expected \r\n form (which most servers are flexible on, but is actually in the spec), although I think it does use that form for pressing Enter/Return within the box regardless of OS.
Removing or modifying headers that don't make sense for a particular verb.
Reformatting the body when you manually change the Content-Type, or vice-versa (changing the header).
Ensuring your headers (or first line) are nicely formatted (or even just well-formed) and have sane values (your x-request-intercepted header is missing a space, and although I don't think that matters I could be misremembering or the server might expect it anyhow because it's typically there).

If you want to compare a request you hand-crafted vs. one that is machine-generated, you can try the Raw tab but the Hex tab is actually more informative; it won't hide things like newline style or other non-printing, whitespace, or similar-looking characters. You can also easily try many small iterations on a request in Burp by using the Repeater tab (most easily done by clicking Action or right-clicking in the request text area and choosing "Send to Repeater"). Repeater is tabbed, remembers history, and can show multiple variants of the same request in different tabs.

At the end of the day, HTTP is all just bytes, and that's what Burp sends. Whether the bytes were manually entered by a human user or added/changed by Burp's request/response modification features is irrelevant. You could also send the same bytes using netcat (nc, ncat, or netcat, depending what you have installed), or any other program that can interact with the network using TCP (and, in the case of HTTPS, TLS; you don't want to try doing the TLS handshake and cryptography manually).


What ports should be closed in windows 10?

How can I close ports in windows 10 and what ports are unnecessary to
  be open?

You can either use embedded windows firewall to do that, or can use the firewall on the router, if it supports acls

  How do I find these open ports to close?

You can use this command:

netstat -an

Or you can use a port scanning software to find out what services are waiting for incoming connections on your PC.

Or you can investigate the rules on your Firewall to determine them. Understand that firewall turned off means no ports are filtered, and no explicit rule "deny all"
also means that ports not explicitly closed will not be filtered.

  Also if I close a specific port on windows 10 do I have to close the
  outbound and inbound port?

Inbound ports means that something can be relayed to your PC through that port. Imagine a fence with 65535 pickets. Each number represents a single picket. Open inbound port with number 80 for example, means that the picket number 80 is not present in the fence. On the technical note, port 80 are reserved by ICANN for web servers on http protocol, so having it open on an average user PC means something fishy.

Outbound ports means that your PC will connect to another PC\Server\Application on PC\Server\Whatever via that port. It will not connect by creating a packet from port 80 to create to port 80 on a target, but rather send the packets to the open port 80 on the target.

Originating packets use dynamic ports to connect to outbound ports. But that is too deep already.


Apache itself should not serve files outside the configured DocumentRoot.

The behavior you are describing is most likely caused by the browser, which transforms the URLs before sending them to the server.

If you use an intercepting proxy, you will notice that for http://localhost/ati/../test.txt, the browser actually requests http://localhost/test.txt and for http://localhost/ati/../../../../../../../../../../../etc/apache2/apach2.conf, http://localhost/etc/apache2/apache2.conf is sent to the server.

If you want to check the path traversal vulnerability you should use a proxy.


I try not to do this but this is very much a yes and no answer.

Tools like FTK Remote Agent run as a service on the system. An investigator can connect to those tools and perform tasks (such as pulling a remote image of that particular system.) If you were to walk into the data center of AWS and could get console level access and installed than ran your tools from there, you would be doing a very similar thing (and actually better since you have less network for potential problems.

If your goal is to preserve the state of the machine as it relates to AWS, pulling an image from the VM may not be the way you want to approach this. The more preferable method would likely be to clone the virtual files that make up your AWS system.

I try to think of virtual environments and forensics in this way, what would I rather have, a copy of the files that make up the state of an OS, or a copy of the container that has the entire state of the OS as it relates to its current environment.

FTK will provide you a clone of your OS from the OS's perspective into a format (ISO most likely), but if you could pull the AWS files that make up the entire VM, you have, IMO more solid forensic evidence.


How to go about password hashing when constrained to low work factor

It shall first be noted that password hashing is a second line of defence. You store in your server's database some value which allows password verification; your first duty is not to allow outsiders to grab a copy of that value. So first apply all security updates for your software; develop code with great care and appropriate methodology (e.g. when accessing the database, use prepared statements); and mind your operational procedures (don't leave your backups unattended, destroy hard disks upon decommissioning, and so on).

Using slow hashing is meant to make the task harder for the attacker in case he still succeeds at getting a glimpse at your database. Unfortunately, this makes password processing harder for you too, so that's a trade-off. With bcrypt, a work factor of n means that there are 2n internal iterations; a work factor of "10" means that you have made dictionary attacks about a thousand times less efficient (since 210 = 1024). Depending on your outlook, this may be great or insufficient, but this is still non-negligible.

To improve things, there are various methods that you may want to consider:

Use a "pepper", i.e. an extra server-wide secret key; this turns the password hashing into a MAC. Basically, when you "hash the password" (upon registration, and upon verification), you compute HMAC/SHA-256 over the password, encode the 32-byte output in Base64 (so that it becomes a nice string of printable characters), then use that string as input to bcrypt.

That process improves security under the assumption that the attacker may get a copy of the hashed passwords but not of the whole server (e.g. the attacker could make some SQL injection but not read the server configuration files). In particular, don't store the key in the database itself.
Help users choose stronger passwords. Mind the words: I said "help", not "force". In particular, do NOT try to enforce "password complexity rules" like requiring a mix of uppercase, lowercase, and sumerian ideograms. Such rules, in practice, do not make passwords stronger; they just make users angrier. Instead, a good thing would be to offer a generator tool that produces high-entropy but easy-to-memorize passwords (see this question for guidance). It is important that the tool is optional because you want users to freely cooperate with your security strategy; if you make anything mandatory then they will rebel and things will be worse.
Offload the problem into the hands of somebody else. This means authenticating users through something like OpenID; the OpenID provider is an external system that handles the password verification for you.

A notable example is StackExchange itself: although they can handle the password registration and verification themselves, they also allow you to register using your existing Google or Facebook account, or just any OpenID provider.
Buy a bigger, more powerful server.


At some point the user needs to be authenticated. The approach that you are detailing will shift this process to the authentication of the email account. Technically it could shift it elsewhere too, but at some point there will need to be a form of authentication.

The problem with delegating the process to a third party is that you place too much trust in (a) their security mechanisms, and (b) the non-secure transport channel for the email. Each of these creates threats that otherwise wouldn't exist in that (a) a poorly protected email host may allow an adversary to access your authentication emails, exposing the fact that your website utilises this mechanism, which means that they simply need to submit a new request, and (b) interception of the authentication email results in the same outcome.

The use of a password introduces a secret that is shared by only the authenticator (your site), and the user wishing to be authenticated. It exists in electronic form for a very short period of time, and within a security environment for which you define the level of protection relative to the threat model.


Can an iOS/android app encrypt data without the user entering a password?

Essentially, yes. However newer devices have a key built into the device that can't be read, only used (the 'Secret Enclave').

Based on that, IOS provides something called the Data Protection API (DPAPI) to apps. You can only crack that if you jailbreak the device and know the device's passcode.

Edit - I said "essentially yes" because I'm a bit cynical about the passcodes people choose - a 6 character alphanumeric passcode would (says Apple) require >5 years to crack, but 0000 or 1234 will be quickly guessed of course


I am getting "Your connection is not private" error and it disappears when I use a VPN

This looks like a man in the middle attack but not  on your computer but instead on your network - otherwise the problem would likely not vanish if you use Tor or VPN.

This might be because you are using an insecure network (like an open WiFi hotspot) where somebody is doing an attack or because your private network is compromised. The latter could be for example because of an attacker in the local network or because your router was compromised - for example with something like DNSChanger.

In case of a compromised router doing a reboot or (if does not help) a firmware reset of the router might solve your problem temporarily. But you should better make sure that your router will not be attacked again by updating its firmware with a fixed version from the vendor (which hopefully exists).


Best way to scan for and eliminate earlier versions of SSL/TLS in a production environment

@atdre points to a tool that should allow detecting whether a given server supports TLS 1.2, but this is only part of the story. In SSL/TLS, the initial steps of a connection are the handshake in which a number of parameters are agreed upon between client and server, including the protocol version that will be used. The client announces the highest protocol version that it supports, then the server chooses the version that will be used (normally, the highest version that the server knows, but no higher than the maximum version announced by the client).

Therefore, even if all your servers are ready to use TLS 1.2, this does not necessarily imply that only TLS 1.2 will be used; it depends on what the servers would accept besides TLS 1.2, and what the clients support. For a given server, you have basically two methods to ascertain that TLS 1.2 will be used:

Make sure that the server supports only TLS 1.2: if a client announces "TLS 1.1" as highest version, the server should reject it. If a server accepts only TLS 1.2, then only TLS 1.2 will be used when talking with this server.
Check that all clients that talk to the server announce TLS 1.2 as highest version, and the server accepts. This basically entails running a network monitor tool (e.g. Wireshark) to observe the ClientHello messages actually sent by clients, and the ServerHello messages sent in response.

Further complications come from the "auto downgrade" behaviour of some clients (typically Web browsers). The client may try to connect, first, by sending a ClientHello that says "I support up to TLS 1.2". If that fails, though, the client may think that the server might be allergic to TLS 1.2 -- it is known that there are still a few deployed Web server that do not follow the specification properly, and simply drop connections when they see "TLS 1.2" because they do not understand it. In order to support these poorly implemented servers, some SSL/TLS clients, upon a handshake failure, will try again, this time with a ClientHello that announces "I support up to TLS 1.0".

Unfortunately (for your present situation), this means that even though a client and server seem to use TLS 1.2 under normal conditions, an active attacker may abruptly break connections that begin with a TLS 1.2 handshake (the active attacker injects spurious RST packets to kill the underlying TCP connection). In such a situation, the attacker may trigger the auto-downgrade mechanism, and force client and server to use a lower version.

So if you really want to make sure that only TLS 1.2 is ever used, even in the presence of a crafty attacker, then only the first method should apply. In other words, using sslyze or any other similar tool, you must make sure that when a client asks for TLS 1.2, it obtains TLS 1.2, AND also that if a client asks for TLS 1.1, the server rejects it.


Securely transport secret token so it can not be used even if snooped?

TLS is designed to protect data in transport. I would recommend you to use it, since you are unlikely to come up with a better alternative on your own. Force all users (end users as well as self hosters) to use TLS, and never allow e.g. plain HTTP.

As a general rule, you should never try to implement "secure communication without TLS". Many have tried, few have succeeded.


Understanding which privacy tools provide very similar functionality

They are not all for the same purpose nor work the same way, but some of them do have overlapping features. They are not all essentially the same, but you can divide them into these categories:

Ad blockers: UBlock, Ghostery, AdBlock Plus. They destroy annoying elements from websites – those that are trying to sell you something you don't need (or show you tits when you are not in the mood). It might be good to have one from this category, but not more.
Less tracking: Lightbeam, Disconnect, Privacy Badger. These block cookies or other common elements between sites that can be used to combine your visits on different sites i.e. track you. They don't really care what you'll see, and they are less dependent on predefined list of "unwanted" servers or sources. I think Lightbeam doesn't block anything but lets you see what's happening.

Privacy Badger has a list of know tracking sites but it also learns from your visits. Privacy Badger can remove some ads too, but if you really dislike ads, even still image banners, ad blockers are needed. Ad blockers can prevent Privacy Badger from learning new things, but the outcome with both enabled is similar. Read more from: How is Privacy Badger different from Disconnect, Adblock Plus, Ghostery, and other blocking extensions?

Self-destructing cookies deletes cookies when you close the browser, no matter what site.
NoScript deals with all scripts rather than adds/tracking, and has opposite whitelist based approach. NoScript removes some ads merely as a side effect. It doesn't handle tracking cookies, but it can help against browser fingerprinting by giving out less information.
HTTPS Everywhere has least to do with anything before: it prevents HTTPS downgrade attacks.

You don't need several tools from a single category, but you may want one from every category as they work against different problems. While some tools might coincidentally end up doing tasks of another tool, this layering becomes handy when you whitelist a page on one tool. Say you want to disable your ad blocker on a media streaming site to be able to watch a video, or trust a site to run scripts mandatory for it to work properly, but the Privacy Badger still removes tracking elements etc.


Does Microsoft's "Password Ban" list insecurely store user passwords?

We, at Microsoft, are banning the passwords most commonly used in the attacks and nearby variants. We aren't basing this on our user populations, who (because of the system) don't share these passwords unless the attacks change.

The attack lists generally derive from studying breaches. Attackers are smart enough to look at lists to figure out high probability passwords, then do their brute force, etc. around those high frequency words. We look at the same lists plus the attack patterns to determine our ban lists.

Hope this helps.


Threema: Are received messages exposed, when sender's private key gets compromised?

For a Diffie-Hellman key exchange the shared secret created will be the same if the same key pairs are used. This means that if Eve gets hold of a private key of either sender or receiver then they can compute the shared secret and decrypt all past and future messages between Alice and Bob. The common way to get around this problem is to use ephemeral keys so that the shared secret is only valid for that specific session.

For Theema however they've decided not to use ephemeral keys on the end-to-end encryption and instead only ensures forward secrecy on the transport layer as stated on their cryptography whitepaper. Their stated justification is:

  The risk of eavesdropping on any path through the Internet between the sender and the server, or be-tween the server and the recipient, is orders of magnitude greater than the risk of eavesdropping on the server itself

So to answer your question directly, for Theema's messages there is only forward security on the transport layer so IF an attacker has the encrypted message AND either the sender's or receipient's private key then they can decrypt it.


When is memory allocation/layout deterministic?

Part of the problem has to do with what the memory layout looks like at program initialisation and what the memory layout looks like after it has been running for a while and you manage to get your buffer to overflow.  You also have to contend with the 'works on my machine' issue.

So at initialisation, all the environment variables will be loaded at the same place because this is a reasonable fixed and early process.  When it comes to overflowing the buffer you cannot always ensure that you are triggering it at the same time each and every time.  for example if the application receives network packets, it would be very difficult for you to send exactly the same packets all the time.  So as a result by the time you come to trigger the overflow the memory layout may not be exactly the same.  Hence the need for the NOP sled as somewhere to 'land'.

The 'works on my machine' problems is that, really, you want your exploit to work on other peoples machines, and they are unlikely to be configured exactly like yours is.  There may be different versions of libraries, different hardware configurations, all of which mean that the target overflow address is unlikely to be the same as yours.

These problems can make it hard to ensure that the memory layout will be the same all the time, so instead you work on a range of likely values and hence the need for a NOP sled.


What you are referring to is called a captive portal. It allows WiFi providers to authorise users, get confirmation for service agreement from them, display ads, require payment for extended usage time, etc. Its existence doesn't have security implications in itself (unless it was poorly implemented and leaking user-provided information, but that is on a different level).

However: when you connect to a WiFi which you do not control, from the moment you connected your device to the network your traffic can be (and is) captured and altered (this is why you are redirected to a captive portalーit is not used as a tool for MitM attack, it is the result of MitM attack*).

The only line of defence, is proper use of HTTPS for the sites that process sensitive information (after authorisation or whatever captive portal requires you to do). It means: (1) using HTTPS in the first place and (2) not accepting untrusted certificates.

* I use phrase "MitM attack" here to refer to the mechanism, not to the intentions. In case of reliable free WiFi providers it is not an attack, but their service model. And as you noticed, Microsoft recognises such actions as legitimate and displays a user-friendly notification.


PCI DSS 3.0: 11.3 - What happens if a low risk vulnerability prevents compliance with another requirement?

Yes, you are responsible for addressing any gaps that you are aware of. It does not matter how you became aware you had a 1.3.8 violation; you're responsible for remediating it. The fact that it doesn't meet the threshold for remediation under 11.3 is not relevant.


What are the main differences between a Metasploit vulnerability/exploit attack and a "R.A.T." attack?

I think you are confusing a couple of different ideas. Metasploit helps you leverage vulnerabilities in order to craft exploits. Those exploits are used to deliver payloads. The resulting code can be something the user needs to install, or Metasploit can allow you to deliver the exploit directly without the user being involved (depending on the vulnerability).

The payload sent by the exploit can be many things, one of which is a RAT (called Meterpreter in Metasploit). But it can also be other kinds of payloads.

The scenario you describe for a RAT does not require an exploit or a vulnerability: you suggest the user just clicks on the malware and runs it. For that, you do not need the resources of Metasploit at all, although Metasploit could be helpful by providing the Meterpreter and the control hub.


When is it appropriate to provide clickjacking protection one of my websites pages?

In general, every page which allows the user to change data is a potential target for clickjacking. The goal of clickjacking is to trick the victim into taking actions on the attacker's behalf. This affects every page with forms or buttons or other UI elements which have persistent effects.

However, I strongly recommend against taking the blacklist approach and picking individual pages for protection. It's very easy to overlook something, the pages may change over time, and even a seemingly harmless page can become dangerous through an additional vulnerability. For example, the attacker might have found a cross-site scripting vulnerability on your site. By combining this with clickjacking, they may be able to take arbitrary actions regardless of what you originally designed the page for.

The correct approach is whitelisting: You protect every page except those which absolutely must be framed.

Note that setting the header to anything other than DENY isn't reliable. When faced with nested frames, current browsers usually just check the top-level site. This means you can end up with situations like this: You allow the site good.com to embed your page as a frame, but this site also embeds evil.com. This allows evil.com to frame your page despite the X-FRAME-OPTIONS header being set to good.com, because the top-level site is indeed good.com.

So if you do allow framing, expect the page to be framed on any site, not just the one you've chosen.


SQL Injection if table structure/db structure not known

In addition to what Philipp said, keep in mind that SQL injection attacks are quite often done without knowing the structure of the DB, but once a vulnerability is exposed, it can be used to determine the structure.

For example, one of the first SQL injection string that was once taught used to be ';shutdown--

This makes an assumption that the data user provided was being put in quotes in a SQL query, so the first quote in the string closes it, and the following semi-colon ends the statement, which may result in an error. However, the following statement would still be executed, which would be shutdown. -- indicates that the rest are comments. So, this string could shutdown a server immediately if the input was not sanitized.

Taking the same one step forward in many DB systems, such as SQL server, the list of system tables is well-known and if the account which was executing the query had privileges, it could be used to list users, tables, stored procs, views, and other SQL configuration. Once that is listed, they can dropped, exported, and the structure of tables or views could be listed too.

Similarly, queries can be constructed to bypass authentication, for example by a string such as ' or '1'='1' --

A string such as the above would be inserted in a WHERE clause and no matter what user name or password was provided, this would result in a true evaluation, allowing user to authenticate without providing any credentials. e.g.:

SELECT * FROM USERS WHERE UserName = '' or '1'='1' --

In short, once a SQL injection attack is successful, the attacker has the ability to run code on your server which should be considered the same as if they were sitting on the server itself in terms of threat modelling.

To avoid the attacks, most frameworks and DB systems provide mechanism for parameterized queries. Although you should check for your platform, parameterized queries is usually the most secure way. If you must construct SQL queries yourself (e.g. to pass to some external API that requires it), then consider encoding it properly although I would try to avoid it.


Good steps to survive from denial-of-service attack (DoS attack)

To avoid downtime during DDoS running single server, you can make sure that your operating system remains stable during DDoS, so when the attack is gone, it continues to work. This can be accomplished the following way:

Setup IPTABLES with rate limit
Add Varnish proxy and configure it to deny attacks, it's stable and very resilient and has some modules to support it.
Enable syncookies
Use latest Linux kernel

This is very difficult thing to do and not straight forward, that's why the answer is a bit vague, and hardly you will get anything else.

In essence, you should make sure that flood is not reaching your application level causing server to choke, but instead dropping connections.

See this on Server Fault:

https://serverfault.com/questions/417969/how-to-tune-linux-kernel-to-withstand-ddos-haproxy


RSA and AES combination in offline situation

The idea of using symmetric keys on top of asymmetric encryption is derived from the fact that online communication channel cannot afford the computation required for asymmetric encryption at all time, should they meet some performance criteria (e.g. time). Having an asymmetric handshake ensures the confidentiality of the symmetric key to be used with the cheaper symmetric algorithm for the session. This sessions is meant to have a rather short duration before you expire its key. This is due to the fact that the symmetric encryption can be broken in shorter times than the asymmetric one. However, the data transmitted over such a channel are usually no more relevant when this can theoretically happen (plus the fact that the message itself is not cached on extended period).

If your data cannot harm you if they are decrypted in let's say 3 months, then the symmetric encryption is a good way to go. However, you still need to ensure that you won't re-use the key of this communication for another communication (I guess this is what you meant by saying "the symmetric key should not be stored in disk" ?). If your data has a longer expiration date, you should probably look toward a two-way asymmetric encryption (with each client/server having a key pair that is). Being offline, the time required to encrypt the data is irrelevant and the offline process is more prone to leave "traces" of your encrypted data somewhere.

You asked also "is that secure". Well it depends on what "security" you are looking for. No security if perfect. Even asymmetric encryption requires you trust the mean used to get the public key. I hope the previous paragraph gave you enough clues as how to assess your risks, therefore decide how secure you are.


How can an attacker redirect victims through proxy

If the attacker is behind a NAT of some sort, then no it will not be possible to redirect the victim to a service hosted on the attacker host or establish a TCP connection from the victim directly to the attacker host.

Indeed, by default, NAT router only allow outgoing traffic and will block any incoming traffic. The external victim will not be able to contact your machine directly, but you will be able to contact the victim unless it is itself also behind a NAT router (which is the case for most end-user systems).

As the attacker, doing such thing will therefore require to change the NAT router setting to associate a listening port on the router to your own host (this would obviously require to have administration privilege on the NAT router). You could also use an external host as relay to bypass the NAT limitation, but then it would by far be easier to just host the phishing site directly on this external server.


I usually use the Krakatau (dis)assember https://github.com/Storyyeller/Krakatau for examining and tweaking Java bytecode files.

The only way to get code into a JVM is to implement a class loader. The bytecode that goes into the JVM is, of course, in plaintext. So, disassemble the local classes first, locate the ClassLoader and hook the ClassLoader to dump the bytecode that would be loaded to a file (and possibly, load replacement code if you want).

Good luck, and don't do this in USA, as it is probably a DMCA violation.