Capture wireless traffic in PROMISCUOUS mode (not monitor mode)

I am trying to capture packets from other devices that are connected to the same network as I am.... I feel that promiscuous mode is more useful.... the traffic is encrypted.

Promiscuous mode is likely not what you want.

To cite from the WireShark Wiki: "However, on a "protected" network, packets from or to other hosts will not be able to be decrypted by the adapter, and will not be captured, so that promiscuous mode works the same as non-promiscuous mode."

Note that this is not a restriction of WireShark but a restriction due to the design of protected WLAN. Thus it will not help to just change the capture tool.

See also Wireshark - I can't see traffic of other computer on the same network in promiscuous mode.


It is implying that trim() doesn't remove internal spaces. For instance, it wouldn't make the command pwd && ls become pwd&&ls. Using this hint, and looking at the imperfect blacklist, you should be able to identify a weak spot in the list.

Hint: The last item in the blacklist is a clue.


No.  You shouldn't hardcode admin credentials into the client code.  Have you considered running a server whose public interface has exactly one operation it supports (create_new_user)?  Or implementing a stored procedure in the database to support this operation (if CouchDB supports stored procedures)?
I don't understand what you are asking here.  Maybe more explanation is needed?
I don't know.

P.S. Since you have 3 questions, I suggest asking them separately.  I think you are more likely to get useful responses that way.


Since you do not mention OS:
http://man7.org/linux/man-pages/man3/bzero.3.html - it's fairly ubiquitous.

Use explicit_bzero() to avoid the compiler accidentally trimming away your wipe for whatever reason. If you kill off the sensitive program and fork a few processes that each gobble say, 512M, you have achieved what you need. Remember to unmount swap first - even before running your sensitive program.

You can set the children to each chunk as much memory as you like. The reaper will clean them up when they hit memory limits.


Is SSL really insecure on most of the web? This report seems to suggest so

Is this overly alarmist?

To a point, yes, it is alarmist. Certainly better to be concerned and care about securing communications though.

  Does that survey somehow paint a picture worse than it really is?

You may not be taking in enough understanding about the types of attacks or requirements to launch one, causing the slight jump to mistrust. Such as you make no mention to understand that this survey reflects site owner's configurations and not representative of the TLS/SSL packages current or updated state such as the latest from openssl.

  Does TLS/SSL seem like a really broken concept if it's repeatedly circumvented from a tremendous number of angles?

No, a symbol of a strong system is to be able to find and fix mistakes. To have a plan to patch or mitigate with supported upgrade paths and a large community assisting with expertise and monetary means. Take your jump at beast attack numbers, you could easily brag about those heartbleed numbers being low and have opposing confidence. Also openssl and other implementation packages are not to blame here, this survey paints the picture of what are the site owner's configurations not the state of SSL/TLS package capabilities that are well maintained and updated.


Nessus scan reports a Dropbear vulnerability on a machine that does not have dropbear installed

To help anyone who comes across this with a similar issue:

After attempting to SSH to the machine being scanned with putty, it was clear that the machine refused SSH access due to sshd_config not allowing root access.

The putty event log showed that the server was reporting an outdated dropbear version in the banner message, which is what caused the scanner to raise this error.

You can double check that the scan did actually successfully connect to the machine by checking plugin 19506 and verifying that 'Credentialed checks' reports a success. Also check that the machine you are attempting to connect to is properly configured and allows SSH connections.


When I register on a website, is there a way to know whether or not the site admin will be able to see my password?

If the admin really wants to see your password, then he will be able to do so. He just has to grab it when you send it to the server.

If you want to know what password-dependent data is stored on the server side, then that's another question. In general, you cannot know how they do things, but sometimes you get clues. Basically, the reasonable thing to store is a "password verification token" which is a hashed version of the password, using a proper password hashing function. If they do that, then they cannot retrieve the password and send it back to you. Thus, if there is a "password modification screen" that can show you your password, or if they send back your password to you by email when you click on the "I forgot my password" button, then you know that what they store is unreasonable. Plain Text Offenders is a rage/shame Web site that gathers reports of such occurrences, mostly for being able to point and mock these poorly developed sites.

What you cannot really know from the outside is whether, when they store only hashed passwords, they use a proper password hashing function, or something else. You usually learn how poorly they did things when they get breached in and a list of hashed passwords is extracted: if the passwords get broken at a rate of dozens per second, then the hashing function was quite bad...

Password reuse is too dangerous. You should use a new, specific password for each site -- that way, any ineptitude on their side will be contained to that specific site. To remember all these passwords without having an enormously efficient brain, you may want to use a password manager software, e.g. KeePass.


What protection certificates would be required for an application that consists of setup, loading utility and main application?

You need to have one code signing certificate. You should sign every binary with this certificate. So, for example, the generated installer EXE would be signed. If the C++ downloader application is included in the installer, you wouldn't technically need to sign it, but while you're at it, do it anyways.

The .net client app needs to be signed, and the application that downloads the .net app must verify that whatever it downloaded is properly signed by your certificate (not just any certificate).

You may want to run the download via HTTPS (remember to properly verify the SSL certificates, including checking the CN which is often forgotten) as an additional layer of security.

Note that this has little to do with Antivirus vendors. They may have less strict heuristics for signed files (thus sign everything), but the main reason for signing is to prevent attacks.


We do not do product recommendations here, but what you are looking for is software that stores the key in the TPM.  The TPM does not necessarily require a password for the key to be used, but the key cannot be moved along with the drive to another computer.

You should be able to use LUKS with the key stored in the TPM (there is a project for that called tpm-luks: https://github.com/shpedoikal/tpm-luks).

I don't think there is a turnkey solution for this; I would expect it to require some effort on your part.


Chrome: Found a crash, is it a security vulnerability?

I suggest reading Best way to triage crashes found via fuzzing, on Linux?, which describes exactly how to do a first-pass triage at assessing the likelihood that the crash is also a security problem.  Tools like !exploitable and Valgrind memcheck are your friend.

If it passes the first-level check, the next step is probably to report it to the Chrome folks and let them evaluate it in greater detail.


Does sandboxie "grab" all the system calls?

As a quick starter for 10, see this page:

The driver component of Sandboxie could not complete initialization. This message indicates that Sandboxie asked the system to provide notifications when processes (applications) start and stop, but the system was not able to accomodate this request.
In technical terms, Sandboxie is asking to register a process notification routine, and this request has failed.

The call in question is PsSetCreateProcessNotifyRoutine
Then this page

The driver component of Sandboxie could not complete initialization. This message indicates that Sandboxie could not intercept and extend some system service.

So the answer is this package is installing a kernel level driver to hook system calls, or rather respond to kernel events and alter the outcome. My knowledge of kernel-mode programming is limited, but I suspect functions such as IoRegisterContainerNotification can be used to create hooks into IO activity and determine what to allow and what to block.
I should advise you - this level of operation is different from a rootkit only in terms of intent and install method, i.e. that you are consensually letting this driver be installed and that you trust it. This software appears entirely innocent but you should be careful when deciding whether or not to install software that does this sort of thing, so evaluate solutions like this carefully.
Edit Just for interests' sake I ran dumpbin /IMPORTS SbieDrv.sys. This driver imports functions from FLTMGR.SYS, the Microsoft File Filter Manager. It also imports amongst many other things PsSetCreateProcessNotifyRoutine from ntoskrnl.exe, the Windows kernel. Just to confirm the above.


With SSL: not saving sessions, cookies not being sent

By trial and error I found the answer:

It seems that when SSL is used (test 2), setcookie is required as follows:

setcookie('sessionname', session_id(), time()+whatever, '/', 'theSSLhostaddress', true, true or false);

Also, the htaccess works in test 2.

The non-SSL script (test 1) did not require setcookie!

Hope this helps.


Google Account collecting browser history and cookies?

Browsers generally implement a level of isolation between the websites and the browser. So a website may not be able to directly fetch the browser history or cookies created by other sites. Services like Google, Facebook, Twitter etc are ubiquitous due to ads, like buttons etc.

It is possible for these services to fetch your browsing history by indirect ways. They won't be able to get all the cookies on your browser though as the cookies are bound to the url that created them.

  What will happen if I login in Google Account and keep it logged in. Will it collect my browsing history and cookies?

Browsing history via browser? No. Google ads can create cookies saying you connected to this website that uses Google ad. This data can then be used by Google to build your browsing history

  What will happen if I logged out after successful login in Google
  Account. Will it be able to collect my browsing history and cookies,
  or something else?

Logging out temporarily stops the Google service from being able to link the browsing to your account. When you log back in, Google can look at the cookies that it stored to get an idea about the browsing history on that macine and possibly link it to you. Of course, it won't always be able to link that browsing history specifically to you. For example, if you are sharing a browser with multiple people, Google may not know who was particularly browsing the computer if nobody is logged in.


Is limiting/cutting password-length without notice insecure?

Absolutely - and "without notice" is pretty bad here.

Your example (a construction that starts with a word and has more complicated bits at the end) is a good one.  XKCD's "correct horse battery staple" would also be reduced to just the first word, making the space trivial to brute-force.

If a security-savvy user is aware of this restriction, they could choose a different password construction, but that's a really terrible thing to ask users to do.  An security-savvy user who is unaware of this restriction could easily end up with equivalent security to your average hunter2 password.


Does the use of the non-registered domains in SPF records introduce a security risk?

You didn't really get the meaning of the EXISTS, I believe.
What you describe (allow example.com to send mail from example.org) would be INCLUDE! INCLUDE:example.com means see the spf record for example.com and apply the rules.

EXISTS is much simpler. It means "If the given DN resolves to any address, it will match (no matter the address it resolves to)."

So the rule "v=spf1 exists:example.com -all" is pointless really. It means if example.com has any IP set, pass the rule, else fail.

The EXISTS rule only makes sense with macros. For example, you could use v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all to make the recipient check a IP blacklist and fail if the sender IP address is blacklisted.
You could also do things like check if the user exists for the domain and a lot more powerful stuff.

To your question if this should be "marked as a potential risk".
No, there is not more risk than in any other SPF setup. If you setup SPF wrong, you could create problems. But this is always a risk. If you use something wrong, bad things can happen. EXISTS or even INCLUDE is not any more risk than other SPF options.


It is actually URL-Encoding and decodes to this:

cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n

Its some kind of PHP interpreter exploit I think. You can read about some more of this here:
Protect against POST //cgi-bin/php attacks?

Btw: The actual code they are trying to inject is probably in the POST-Content. (Most likely not logged by your webserver)


Is array injection a vulnerability and what is the proper term for it?

I think the term HTTP parameter pollution would be the best fit. This type of pollution usually submits the same parameter multiple times with different values in the same request. This results in the parameter being treated as an array of values with the parameter name as the array name as described in this article. The way the web server and programming language handles these arrays compared to the single value is what this bug class exploits.

Your examples similarly cause an array with the same name, although through a different method to repeating the parameter, but it seems like a better fit compared to other terms like fault injection or type confusion.

While this type of pollution usually exploits undefined behaviour, the examples you have provided would not. They would cause defined behaviour for handling an array. This may still trigger exceptions which could be used to alter the flow of an application, such as erroring out before a authorisation check changed your session resulting in a privilege escalation.


Go to about:preferences#privacy, scroll down to the bottom under "Certificates", click "View Certificates", then go to the "Authorities" tab.

Select each certificate authority you want to distrust, then click the "Delete or Distrust" button.

There doesn't appear to be a simple way to restore trust in a built-in CA, so you may want to be extra careful in distrusting built in CAs - in particular, not all well known CAs have well known issuer names: "Let's Encrypt", for example, is issued by "Internet Security Research Group", so distrusting the "ISRG Root X1" certificate would distrust "Let's Encrypt" (well, they're cross-signed, so would keep working unless you also distrusted IdenTrust, which also doesn't sound like it's related...).

You need to decide what counts as untrustworthy for your use case - if you need to deal with the Finnish government, say, you need TeliaSonera. If you don't, and you don't need any other sites using certs signed by it, you probably don't.

The options are basically:

decide which CAs you trust, and remove all others, living with breakage of sites signed by other CAs,
or work out what sites you use rely on, and perform more detailed checking of those CAs until you feel able to trust them, or can replace those sites which rely on them with others using CAs you do trust.


Is letting users run lslogins on a shared host a security risk?

Unix and similarly Linux were designed to support multiple users from their very inception. As such, there is a fair amount of security to restrict a user's ability to attack other user's processes and such. While knowing who has an account on your machine may help you in an attack, it is likely not the key component, and not considered a terrible problem in the Linux model. This is fortunate as it can be difficult to restrict access to /etc/passwd file (the source of data for lslogins):

  It should have general read permission as many utilities, like ls use it to map user IDs to user names, but write access only for the superuser/root account.


Minimum number of bits to prevent hash collisions?

Any unbroken n-bit cryptographic hash function has a collision resistance of 2n/2. This means that, if you want to have a 2128 collision resistance, you need to use, at minimum, a 256-bit hash function. As 264 operations are achievable, you would not want to use a 128-bit hash. A 160-bit hash (that is, a 280 security level) is borderline. Using a 256-bit hash will give you a 2128 security level, which should be completely fine for the foreseeable future. Sometimes, weaknesses in the hash function itself result in it being easier to break than the output digest would suggest. The SHA-2 family of hashes is one example that is currently unbroken. SHA-1 on the other hand is broken. It has a 160-bit output but "only" a 263 security level against collisions, rather than 280.

I suspect you may be mixing up collision attacks with other types of attacks. A collision attack will not allow an attacker to find input that hashes to an arbitrary value. The formal definitions:

Preimage attack - Given h where f(m) = h, find any m' such that f(m') = h.

"Find input that hashes to an arbitrary value."
2nd preimage attack - Given f(m) = h, find any m' such that m ≠ m' and f(m') = h.

"Modify an input without changing the resulting hash."
Collision attack - Find any pair of m and m' such that m ≠ m' and f(m) = f(m').

"Find any two inputs that have the same hash."

Each attack has different implications. A collision attack is problematic for certificates, as they can be used in signatures that are valid for both benign and malicious versions of the same software. A preimage attack is problematic for verification. Imagine if an attacker could modify an executable without changing its hash. Clearly, a preimage attack is far more severe than a collision attack, but it is also thankfully far more difficult to pull off. The infamously insecure MD4 algorithm, for example, is so bad at collision resistance that it is cheaper to find a collision than it is to run the hash function itself twice. However, as broken as it is, preimage attacks against it are highly theoretical.

If, on the other hand, you simply want to check for accidental corruption and are not intending to protect against an active attacker, then a CRC with a properly-selected polynomial would be ideal. A CRC can actually guarantee error detection up to a point.


Does forwarding a link expose my IP address?

I’m wondering if my friend got my IP because I copied and pasted.

No. As I understand it, you relayed a link from your friend to your cousin, without clicking on it. This does not expose your IP address to your friend.
You seem to attach too much security value to your IP address. You expose your IP address all the time to all the sites you visit, so they can send data back to you. If someone has your IP address, this means that they can attempt to connect to your device, but this is not necessarily a security issue.
If you want to burglar a home, it's helpful to know the address of the home you want to rob, but that doesn't mean that house addresses are kept secret. If you want to receive letters, you have no choice but to share your house address.


What cipher suites and protocols are being used?

For AWS ELB, you can enable access logs to AWS S3 and get the TLS version and cipher suite for each request: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html

In my experience, TLS1.1 is never used, TLS1.0 is used by bots (that also send a User Agent strings masquerading as real browsers). But your user base might be different.


How to know if virus alert is false positive?

First, you should verify that the email from your ISP is valid (i.e. came from your ISP). I'm not sure why anyone would warn you of a possible infection for malicious intent but, paranoia is not always the worst thing in the world when it comes to security. Call your ISP. Ask them how they caught this.

Unless you explicitly know what you are looking for (socket calls, heatbeats, etc.) it is going to be hard to verify. It's always better to be safe than sorry. Again, call your ISP and see how they fingerprinted this and from there you may be able to narrow down the point of infection.

If it is in fact Zbot then it can be VERY difficult to detect and remove with standard AV tools or even running a script called tron script. You can try your best with the tools at your disposal, and even run the tron script to see if it picks anything up. But, this is one of the prime delivery methods for ransomware, botnets, etc. And as such, it is very well hidden and written.

Here's where the story gets sad, you probably need to nuke it from orbit. I know, this option sucks.. alot.. But, most if not all of us run into this from time to time. Especially in the research realm.


These technologies are similar in that they are compiler protections. To get protection, an application needs to be recompiled, but the source code does not need to be changed (at least, unless the app does something funky, like self-modifying code)

Stack Guard is based on a "canary" value that is put on the stack with each function call. At the end of the function, the canary is checked. If an overflow has occurred, this will corrupt the canary and will be detected.

Stack Shield is based on copying the return address to a safe area, and checking the return address at the end of the function. If the return address is overwritten, this will no longer match and the attack will be detected.

Because they work differently, they have slightly different security properties. In particular, Stack Guard is better at detecting corruption of things other than the return address. And this is why Stack Guard is more widely used.

This paper is interesting: http://www.coresecurity.com/files/attachments/StackGuard.pdf


The best way to prevent ransomware and virus?

Malware is a fast evolving beast and their is no single solution which will protect you. But you can reduce the risk in various ways. First you need to know how the malware gets delivered:

A major delivery vector for malware is mail, i.e. either as an attachment in the mail or mail which includes a link to some site you should visit. While many of the mails look suspicious others are get really hard to detect because they seem to provide expected or unexpected invoices or delivery notices from Amazon, Ebay, Paypal, DHL etc or even have the the of a friend as alleged sender. Typical attachments are various kinds of office documents, PDF or ZIP files containing JavaScript or Windows binaries. Sometimes the real type of the file is hidden, i.e. document.pdf.exe might look like a PDF from name and symbol but is actually a program.
The other major delivery vector is the web. This will be illegal sites where you can watch movies, but more and more malware gets delivered through ads and through formerly trusted but now hacked sites.

Once the malware is on your system it needs to be run to start malicious part. This can be done with exploits or with social tricks:

The major attack targets are Flash-, Silverlight and Java-Plugin, Acrobat Reader, Office and also the Windows system including Internet Explorer. Thus remove anything of these which you don't need (Java, Silverlight, Flash) and keep everything else always updated. There are lots of exploits out there which use problems in unpatched versions of Office, thus if you have some out-of-date Office software which is no longer supported you better remove it.
Other attacks need your help, i.e. they lure you to enable macros in office, to update your Flash plugin with the alleged newest version which the attacker helpfully provides for you, to install some plugin or download program you need to access specific content etc. Or it tries to scare you with some dialog which claims to have found malware on your system and offers you a software to remove this malware. Don't fall on these tricks.

Thus how you can protect against these threats?

Educate yourself and know what can go wrong. Then don't do anything which might be dangerous. Don't open unexpected attachments or links, don't install some software from the internet unless you are completely sure that it is definitely the one you need.
Keep the system clean: Remove any software you don't need or which does not have any more updates. Always get the latest updates for the other software.
Protect yourself with technologies like Adblocking and Antivirus. Use a browser which includes good protection technologies by itself - Chrome/Chromium is probably currently the best here. While none of these  provide fulls coverage they reduce the attack surface (even if some claim that Antivirus is dead).
Always have current backups in case anything goes wrong. These backups should be offline so that they don't get affected. And you should have backups from multiple days in case you realize an infection too late and the backup itself is infected.

There can be much more hardening done, like only run whitelisted applications, disable Javascript in browsers, use virtual machines, using a more secure operating system ... . But after a while these protections get too much in the way of the normal work. Thus you have to find some balance between security and comfort and the risk you are willing to take.


Does adding multiple recipients to an encrypted message decrease security?

Cryptographically, the scheme you describe is not increasing your risk.  From an overall security standpoint, adding the additional recipients creates more points where things can go wrong.

Each of the recipients represents an additional endpoint where the message must be secured.  You may trust each of the people, but can you equally trust all of their computers to be secure?  Having fifty recipients means there are at least 51 attack surfaces involved.
Adding multiple encrypted session keys provides a hiding ground for a rogue encrypted session key.  A human may notice if one key was suddenly replaced with two keys, but might not notice if a fifty-first key was added to a list of fifty keys.


Is it possible to determine password strength without knowing the password?

I would figure there are two ways they've come up with the information that they drew that conclusion from.

They ran the net accounts /domain command on a users computer which dumped the password complexity requirements for your organization (assumes Windows / Active Directory)
They successfully brute forced (or guessed) user passwords because they were weak. Recent password dumps like LinkedIn have provided a trove of real-world passwords that pen-testers have been using in the field to try to crack passwords.

Without further information it's hard to say how they've come to that conclusion (we have no idea what the red team did or what was in scope) but those two ways are how I would assume they did it.


How secure is automatic authentication in Skype?

It is really hard to judge its percentage of security with a couple of queries.

Obviously none of the users who gives "Remember password" option or automatic authentication wants their password to get compromised.

If you really do not want your Microsoft services to be accessed by any other application, then i suggest you consider not merging it with other applications.

And remember that just because of merging your Microsoft account with Skype doesn't mean that your Microsoft account is made less secure. It means that you can have a centralized place where you can manage and access both of your accounts.

Microsoft might not have implemented Google's application-specific passwords yet. But that doesn't make it vulnerable for your password since Microsoft has it's own encryption system which uses some of the top most security algorithms (I do not want to go deeper as it may be off topic).That proves that your password or any other sensitive information will be hashed using an advanced encryption system and secured.

And to answer you question, Yes it is secure (again, not in terms of percentage).


How can I test a DoS attack against snort?

There are many cheap stress-testing services that offer a variety of attack vectors to attack with.

Once you purchase a membership, you simply login to their website and input your site's URL/IP address and chose an attack method (UDP, SYN, HTTP, ect)

Note that these services are usually illegally ran by teenagers trying to make a couple bucks.

Nonetheless, these services are great for testing your website with different attack methods and good for testing the strength of your DDOS protection/firewall.


Getting file from Amazon s3 encrypted based on user

No, there isn't.

S3's encryption services are for the data at rest inside, not outside, S3.


For example, the client can't be sure of the server's identity, and the server can't be sure of the client's identity. Is this the case?

Correct. But validating the server certificates only addresses the first point: that the client is not sure about the servers identity, i.e. that the client might actually be connected to some man in the middle attacker instead who is able to sniff and modify the traffic.
Client identity is typically addressed inside the application protocol (i.e. login with username and password) but can also be addressed inside TLS with client certificates.

... then enter a password in my smartphone app which my server can verify ...  wouldn't this be able to verify the client from the server's perspective?

Yes, this identifies the client against the server. But as long as the server certificate is not checked it might still be that a man in the middle attacker can intercept the connection and just claim to be the server against the client and claim to be the client against the server - then forward, analyse and potentially modify the data between real client and real server. And the attacker could also sniff the password this way and use it later again to impersonate the real client, without the real client being involved at all. In case of the garage door this would mean that the attacker could control the door even if the owner of the garage is not present.
Using a client certificate would protect against this attack even if the server is not authenticated by the client with a certificate - as long as the server checks that the client certificate is the expected one.


Do normal SMS risks apply to DigiCel mobile banking? What mitigations are likely in place?

I read both articles and didn't see SMS banking mentioned anywhere. NFC, Mobile Internet, etc... not sms. So I did a bit more digging and found items such as: SMS Banking - Top Up via SMS which do discus sms and digicel.

Lets be clear, sms is not in any way, shape or form secure.

But from the articles I've found thus far, you can't do very much through sms. Most possibilities include checking balances and mundane things like that. The only possible transaction I've found is the ability to add money to a TopUp account from an already setup/linked Visa/Mastercard/etc. So yes, one could move money from one account you have to another account you have through sms. Not much of an attack vector. You'd have to compromise the TopUp acct/card/phone as well, so if you had your wallet/purse/phone stolen you'd be at a high risk. But one is normally at a high risk when these items are stolen.


How does a sandbox module know the difference between trusted and untrusted code

A well-designed sandbox is simple: all code inside it is untrusted, and has to ask the sandbox if it wants access to anything outside.


There is no sure-fire way to determine IOS and model without getting the router itself to do it. Typically this would be done using telnet or ssh and typing in "show version", which is not an elevated command. Many implementations have poor VTY passwords, so don't rule it out. Also worth trying is using SNMP to poll the router, you can use cisco's MIB browser to find the relevant OIDs. Many implementations also have poor SNMP protection including weak strings and no ACL protection on polling. You can get free net-snmp and ucd-snmp implementations for windows and unix in order to walk the OIDs.

Other than that there's good sense and guesswork which could get you close. Think about the size of the organization and its expected traffic levels in order to reduce the number of model possibilities.


Someone got my ip with grabify, what should I do?

The attacker is trying to trick you into thinking you're compromised, but you're not.
Your IP address is not "private" information. In fact, you announce your IP address to every client you ever connect to, such as any web server of any website you visit, or any other player in an online game you're playing. Just to illustrate my point, in order to visit stackexchange.com, any packet I send is seen by six different hosts - all of which now know my IP address.
Grabify allows users to see from which IP addresses the link was clicked on, and attackers like to use this information to intimidate people. Notice that I say "attackers", not "hackers" - there is no hacking involved. They are trying to intimidate you, claiming that they have attacked you, or that they are going to attack you - and I'm very certain they're going to demand money to "stop the attack" - even though there never was any attack to begin with.

What information does an IP address contain?

Who your ISP is. That's about it. From that, your rough location can be determined, but that depends entirely on how your ISP operates and allocates numbers. For example, I am a customer of a local ISP that only serves customers in my city and the nearby area. As such, if you look at my IP address, you can tell which city I live in. If I were to be subscribed to an ISP that serves the whole country and the ISP would not differentiate at all in terms of network allocation, then the closest you would get is my country.
The attacker definitely does not know your actual, physical location or home address - at least not from your IP alone.

Then how come all these other things happened?

Pattern recognition. It's similar to how horoscopes work. Your horoscope may tell you that you will have a good impact on people, and wanting to believe in the horoscope, every little positive interaction with another person now becomes "evidence" of the horoscope being correct.
Likewise, your modem resetting "out of nowhere" is a thing that happens regularly and has countless normal explanations, such as your ISP restarting a server for maintenance purposes. If that had happened to you before the whole incident, you would not have considered it "weird" or to be some sort of indicator for an attack.

What should you do now?

Nothing. Stop communication with the attacker and just carry on. Any threats they make are just as credible as an email from metropolitan.ploice@hotmail.com telling you that you have to send them 200 USD worth of Steam Gift Cards or you will be arrested.


How to Create file name with Slash in it for Path traversal attack?

The key is in the first line of the third paragraph of the page you reference:

  The vulnerability is exploited using a specially crafted archive...

You don't create a file with a slash in it (and then put that file into an archive), but you create an archive that says it has a file with a slash in it (so when it is extracted it "confuses" the extractor/operating system and creates a file where it shouldn't).

Depending on the nature of an archive, and its internal format, creating an archive could conceivably be as easy as binary-editing an existing archive (e.g. changing SafeNamedFile.sh to ../../../evil.sh), but is more likely to need altering the source code of the archive-creation utility to embed what would normally be an illegal filename.


How can I prove calls or messages from a spoofed number are fake?

First of all, it's important to note that this answer is relevant to United States law, and shouldn't necessarily be taken as legal guidance, more-so a path of reasoning out a solution that may be applicable to you depending on your country etc.

If they choose to actually report the fake evidence to the authorities, you should look into having the police check their call history with their phone service provider, as well as yours. I'm aware of online phone services on the web and through apps that could potentially be used for this kind of thing. Make sure to let the appropriate people know that this is a possibility, in which case they may need to check the suspect's internet history on their computers and ISP.

Faking evidence is unlawful and if you would like, you might could press charges and potentially solve your problem.

Some helpful links below -

https://en.wikipedia.org/wiki/False_evidence

https://en.wikipedia.org/wiki/Perjury

https://en.wikipedia.org/wiki/Malicious_prosecution


You may want to look into setting your webserver to HSTS (Strict Transport Security) which uses a special response header to tell the browser to only accept https traffic.  Full Disclosure:  As you might have expected, IE support < 11 I believe is limited.  If you must use something client-side to check for https I think you could use window.location.protocol.


Do I need to encrypt connections inside a corporate network?

Yes encrypt, it is easy. Plus according to a 2014 Software Engineering Institute study 1 in 4 hacks was from someone inside the company with an average damage 50% higher than an external threat actor.

Link to source: https://insights.sei.cmu.edu/insider-threat/2017/01/2016-us-state-of-cybercrime-highlights.html Although this is the 2017 version.


If you browse websites that start with http, he could view the websites and its subpages you visit, what you post (e.g. facebook posts, google search queries, images) on these websites and that also includes the passwords you use for these websites. This requires more than "basic" knowledge, so even in this scenario, you should be pretty safe. Additionally, almost all reputable websites force you to use https (see below), so you should be safe in general.
If you browse websites that start with https (often browser add a padlock symbol left of your address bar to denote that), he can see which websites you visit (e.g. facebook or google), but not what you do on these websites. For example, he can see that you're browsing Google, but he couldn't see what you're actually searching. He also would not be able read your passwords or any other data you enter or receive there. Note: If one of the websites you click in Google results uses http, he would be able to see everything you do with the website as mentioned above.
Programs that you install on your computer, e.g. Microsoft Word or Dropbox that access the Internet will usually also use encrypted connections, like https. However, there isn't a simple way to ensure that they do. Again, reputable programs will use encryption, and then all he could tell is as outlined above.

If your browser suddenly warns you about an "unstrusted connection" or "invalid certificates", you should be careful about visiting sensitive pages or entering sensitive data (i.e. passwords). This is because those two warnings might indicate that someone is trying to tamper with your connection to the Internet in order to steal your data.


Why hasn't push notification authentication replaced SMS for 2FA?

SMS works on any phone.
Push notifications require installing an app and configuring the account in that app.


How is Facebook accessing my iPhone texts in order to recommend friends?

It's entirely possible that this has no bearing on your own devices or settings. Let's talk about the way one could go about designing that feature:

Consider all connections one or two steps away. From those who have enabled syncing their contacts, consider those with a fuzzily matched name. Factored with some other heuristic scoring, you start seeing people you know in your feed based on information that didn't source from you.

From their own page: We show you people based on mutual friends, work and education information, networks you’re part of, contacts you’ve imported and many other factors. and When your friends join Facebook, they can invite their friends to join too. Their invitation emails can include suggestions of other people you may know who may have invited you in the past. This helps you find your friends on Facebook quickly so you can start sharing with them if you decide to join.

https://www.facebook.com/help/501283333222485/

Thus, there's no inherent implication that something is wrong with your security settings, particularly on an iPhone.


Can Client send Application data in TLS 1.2 or earlier before getting server Finished message?

While I don't know what exactly you've seen the TLS 1.2 explicitly states that  application data must only send after the handshake is complete. This means that both sides has got and verified the Finished message from the other side. This is stated in various parts of the RFC 5246, like

  7.4.9.  Finished...
    Once a side has sent its Finished message and received and validated the
        Finished message from its peer, it may begin to send and receive
        application data over the connection.

Within a full handshake the Finished message is first send by the client and then by the server. This means that the client has to wait for the server to receive and verify the Finished message from the client and then send its own Finished message back. And only after the client received and verified this Finished message from the server it can send application data.

But, within a successful session resume the Finished message is first send by the server and then by the client. And in this case application data from the client can of course follow directly the Finished message from the client. From RFC 5246 page 37:

  Client                                                Server

  ClientHello                   -------->
                                                   ServerHello
                                            [ChangeCipherSpec]
                                <--------             Finished
  [ChangeCipherSpec]
  Finished                      -------->
  Application Data              <------->     Application Data

      Figure 2.  Message flow for an abbreviated handshake

  ... that in some sites clients starts sending application right along with ClientFinished message i.e. after 1 RTT, while in some cases it doesn't and starts sending application data after 2 RTT

One possibility is that you've only noticed that application data from the client directly followed the Finished message but that you did not realize that this was because a session resume happened and thus the Finished from the server has already been received and verified by the client.

But, after you've edited the question and included an image it is obvious that this is not the case and a full handshake was done with early sending of application data. This is called TLS False Start and is defined in RFC 7918. According to this RFC TLS False Start can be done if the client has prior knowledge that the server is compatible to False Start and if strong ciphers white listed for use with False Start are used. For a short introduction into TLS False Start see High Performance
Browser Networking.

  If 1 RTT was already there in TLS 1.2, then why there is so fuzz about 1 RTT in TLS 1.3?

TLS 1.3 changed the protocol a lot. The result of this was 1-RTT instead of 2-RTT for the full handshake and optionally 0-RTT instead of 1-RTT on subsequent connections (i.e. what was session resume in TLS 1.2).


This approach does not seem ideal since it is common to find bypasses when it comes to blacklists.

There are some great resources out there such as "Scriptless Attacks – Stealing the Pie Without Touching the Sill" and LiveOverflow's recent video "The Curse of Cross-Origin Stylesheets" if you are interested in learning more on scriptless attacks that rely on CSS. These links might give you a better idea of what issues might arise as a result of user-supplied CSS.


Vary: origin response header and CORS exploitation

It's important to include the Vary: Origin header to prevent caching. The header indicates that the response is in some way dependent on the origin and should therefore not be served from cache for any other origin. If the header is missing, cache poisoning attacks might be possible as explained in the article by the example of XSS via a reflected custom header. A missing Vary header doesn't create a vulnerability on its own.


Is it true, that using symetric encryption, if attacker knows encrypted text, original message, and algorithm means he can calculate the secret?

No, it is not true.

Being able to recover the key, while knowing the original message (the "plaintext") and the encrypted message (the "ciphertext") and the algorithm, is called a known plaintext attack. If the attacker not only knows the plaintext and the ciphertext, but actually gets to choose either, then this becomes a Chosen-Plaintext Attack or a Chosen-Ciphertext Attack. Good encryption algorithms are supposed to resist such things; meaning that if a known/chosen plaintext/ciphertext attack applies, even if it requires ludicrous amounts of known plaintext (e.g. some trillions of terabytes), then this counts as a "break" and the algorithm is said to be "weak" or "broken", at least in an academic way.

We have several encryption algorithms (e.g. the AES) for which no such attack is known, and that's not for lack of searching for such attacks. So these algorithms are deemed "secure".


nmap mac os lots of questionable ports open

You should read up on what filtered means. It does not mean that those ports are open, but rather that Nmap didn't receive a response from them. On a localhost scan, this is very unlikely, but could happen if you are scanning "too fast" I suppose.

For checking open ports on your own system, your first tool should be netstat. This will show you (among other things) all listening ports. Nmap by default only scans the 1000 most-common ports, so it misses about 64000 other possibilities. Unfortunately, OS X's netstat does not show the process that is actually listening. You can get this information from lsof, though, so try sudo lsof -i | grep LISTEN.

EDIT: Following feedback below, I should point out that a service which is listening only on localhost does not represent a threat from an external attacker. You can determine this by looking at the output of netstat -an: if the port is listed with a Local Address of *:38568 (or whatever port number) then the service will accept connections from outside your own machine. If the Local Address is 127.0.0.1:38568 or ::1:38568 then it is accessible only from the loopback adapter (i.e. not from the network).


School tracking applications with a school computer

Yes it can, if the school installed a tracking program to its computer.


Exploitability of allowed wildcard (*) CORS Origins with Bearer Token Authorization

ACAO: * will prevent the browser from automatically sending any form of credentials, but that's only relevant for the kinds that the browser can actually send automatically (cookies and HTTP BASIC, DIGEST, and NTLM auth). HTTP auth does use the Authorization header, but not with a Bearer token. Because ACAH: Authorization is specified for both the pre-flight and the actual request, the caller is completely free to explicitly attach an Authorization header (with any value at all, including a Bearer token). The difference is that the caller needs to actually know the value to put in that header; it won't be automatically added by the browser.

Given that the attacker would already need to know the bearer token and that the browser isn't automatically including any secrets with the request, there is no security vulnerability here at all. Allowing the browser to make such authorized requests from arbitrary origins is fine; it's exactly equivalent to the browser making a same-origin callback to its own server, and having the server send the request (which would ignore CORS because most HTTP client libraries don't even have a concept of the same-origin policy) and relay the response back to the browser. In other words, this is no greater security risk than any other web service protected with a Bearer token.

Of course, this is all assuming that the web service is supposed to be reachable from arbitrary addresses. If it's not - if for example it's only supposed to be reachable by one company - then it would make a little sense to restrict the allowed origins more tightly. Only a little, though, because anybody with an HTTP client library (and the bearer token, without which the attacker cannot do anything if the auth is otherwise solid) can make requests all day, unless there's also something like an IP whitelist.

The primary and critical part of the security of the service, as you've described it, is the bearer token. To a first approximation, nothing else matters.

With that said, there are of course many other potential vulnerabilities to check for. Obviously, you should verify that the Bearer tokens are at least as secret as the information they authorize access to; it's no good to require authorization to access a web service and then push the required authorization data to a Git repo, for example. Similarly, make sure the valid Bearer tokens cannot be guessed, brute-forced, or found via timing attack. There are lots of ways to screw up auth, and even more to screw up web services in general (is it available over HTTP, or via weak HTTPS cipher suites? Does it have deserialization or XML DTD vulns? Standard web security stuff).


You cannot force token expiration. Tokens expire when its lifetime (determined when constructed) has passed.

You can distribute a blacklist to the points in your system where they are checked (eg api server for remote resource or the app for a local resource) to enable you to revoke them. If your token contains the userId you can distribute a blacklist of userIds and just check if it is on the blacklist. If your tokens do not contain some kind of identifier you have to store the tokens you issue for each user until they expire and distribute a blacklist of tokens.

You could also choose to give your tokens a very short livetime and just wait for them to expire.


Is there a compatibility issue between IPv6 and security testing tools?

Most security tools have had IPv6 compatibility built in for years. For example, see nmap’s multitude of IPv6 options. With nmap6 being launched yesterday, it’s even more clear that nmap is much more than a vulnerability scanner.

Nessus has supported IPv6 since version 3.2, which was out in 2007.

Similarly, Metasploit has had it since 2007 (version 3.1), though it took a few months for payloads, stagers, etc. to catch up.

I haven’t used w3af in a long time, but it also had IPv6 support and since it’s part of Rapid 7, it obviously links in very well with Metasploit (as does nmap).

I don’t play much with code analysis tools, but as far as I know there are no compatibility issues for most.

You’ll obviously have to change your scripts from IPv4 addresses to IPv6 so there’ll be some tedious work there as you check things and validate that everything still works, but in terms of the tools actually working, the compatibility with IPv6 is built in for most of them.


The attacker can modify certain bits of the plaintext (by modifying the ciphertext), but the attacker does not know what the entire plaintext originally was. Therefore, the attacker doesn't know what bits of the hash will change due to their alterations of the plaintext. To successfully modify the hash and the plaintext, the attacker would need to know the difference between the original hash and the hash of the modified plaintext. The attacker doesn't know this difference, which prevents the attacker from changing the hash to match the modified plaintext.

Now, all of this is based on the idea that the recipient is supposed to decrypt the data, then verify its authenticity. While this can be done, it's also possible to protect the integrity of the ciphertext, allowing the recipient to verify that the message hasn't been tampered with before even attempting decryption. Obviously, just hashing the ciphertext and appending it to the end doesn't work, because the attacker could modify that hash. Instead, there are two ways of doing this, based on the kind of crypto in use. They are both hash-based but have extra security beyond simply hashing:

If using asymmetric cryptography, such as the usual way to use HTTPS or SSH, then you digitally sign the hash. Without getting into the mathematics of how digital signature schemes work, the basic idea is that you have two keys: a private key that only you know, and a public key that everybody can get a copy of. The private key is used to sign the hash, and the public key is used to verify the signature. Because the attacker doesn't have your private key, if they modify the message and re-compute the hash, they won't be able to re-create a signature that can be verified using your public key. Therefore, anybody will be able to use your public key to tell that the message they received is not the message that you signed.
If using symmetric cryptography only, like an encrypted .ZIP file or most other forms of password encryption, you create a keyed Hash-based Message Authentication Code (or HMAC). Again, without going into the details, the idea of an HMAC is that when you compute the hash of the message, you also stick in some additional data that is based on a key (which might be the key used to encrypt the message, or might be another one) that the intended recipient of the encrypted message also has. This additional data added to the hash function input modifies the output (the digest) in such a way that if an attacker modifies the message, the attacker won't be able to figure out what the new HMAC should be because the attacker doesn't know the key and therefore, when the recipient uses the key to compute the HMAC of the modified message, it won't match and the recipient will know the message was tampered with.


Flaws in my proposed license verification system?

Your design is the basically the same as most licensing systems. One extra step is to obfuscate your application, so it is more difficult to decompile.

How secure is this? It will certainly hinder a typical user. In fact, even the older system with an embedded key will stop most users. While you say it is easy to extract the key, that is from the point of view of a skilled programmer, not a typical user.

It will not stop a skilled cracker. While they cannot create a fake license file, what they can do is modify the application binary and remove the code that checks for the license. Obfuscation makes this harder, but no obfuscation is foolproof.

The real concern though is that it only takes one skilled cracker to break your application, and they can then put the cracked version on Bittorrent. This may not be the end of the world. Many people will still buy the official version. Perhaps they're just honest, or don't know how to find cracked software, and a lot of people are rightly concerned about viruses coming with cracked software.

Ultimately, while your change is a security improvement, I don't think it makes a material difference to whether your software can be cracked. It does however sound like an excellent usability improvement.


TPMs can seal arbitrary data. When you seal a key, you are not actually storing it inside the TPM. You are sending the raw key to the TPM which encrypts it with an internally protected key (the Storage Root Key, or SRK) and returns the encrypted, or sealed, blob. It is up to you to store this encrypted blob.


How do I know if my email account has been hijacked?

Generally speaking I don't believe there will be an easy foolproof way of detecting whether or not you've been sending out messages given the access you typically have to a web based system (be it Yahoo, Gmail etc). If you had access to the server certainly you could through logging, but not with the information given to us via these clients.

Here are some suggestions through.

Keep an eye on your login IP's if your client provides the capability of doing so. This can flag an attacker logging in from a location you've never been, hence raising the possibility of being compromised.
Education - ask your friends / family to alert you to any strange messages such as the ones you've recieved in the past. The majority of the time I imagine if you're getting this stuff sent out you'll get a few replies from people going "Huh?"
If you really wanted to you could create a honeypot email. Go sign up for some random email  and place it no where else but your contacts in your email. An attacker would almost certainly send messages to everyone in your contact list, not knowing who is legitimate and who isn't. If Mr Smith recieves an email from you, you know your account has been compromised.
Prevention is the best cure, make sure you'll changing passwords regularly and avoiding using the same password at multiple sites.


What are the security implications of having a dummy user account representing unauthenticated users?

It sounds like your following good security principles by establishing secure defaults, trying to keep it simple, and ensuring guests have least privilege.

I think both of the two options are viable and should be left up to you, the programmer. Whatever you think is simpler and easier to manager long term is probably the right choice.

If a visible to public object is going to be easy to manage the access rights on whatever content you wish, use it, as long as it also provides easy functionality to change what's visible in the future.

I personally would lean towards creating a permissions group for guests, and assigning them to that group by default because that's what everyone is used to managing. It would also permit someone to manage the permissions of all the guests in the same way that one would manage the permissions for everyone else. Remember, keep security simple.

  Attack surface area and simplicity go hand in hand. Certain software
  engineering fads prefer overly complex approaches to what would
  otherwise be relatively straightforward and simple code. Developers
  should avoid the use of double negatives and complex architectures
  when a simpler approach would be faster and simpler.

Read more on security principles here - owasp.org


How Secure is Googles Saved Password feature?

Came across this post:

How they work: Browsers store your passwords in encrypted databases or registry entries stored locally on your computer. If the browser has a feature to sync your data between your computers and other devices, the information is saved in its encrypted format to an online account (e.g., Google if you're using Chrome or your Firefox Sync account on Mozilla).

Security weaknesses: The biggest problem with saving your passwords in your browser is that it's not hard for someone who gains access to your computer to also access all your passwords. In Chrome, for example, you (or anyone who hacks into your computer) can just go to the browser's settings and click on the show button in the preferences tab to reveal any saved password. Internet Explorer is more secure because it doesn't let you view saved passwords, and it also doesn't sync your data across computers. Both IE and Chrome, however, use your computer login password as the cipher for the encrypted data. Because of this, it's easy for your passwords to be revealed with tools such as Nirsoft's WebBrowserPassView. If third-party utilities like this can recover the data, malware running under your user account might also be able to access the data.

Link to full article:
http://lifehacker.com/5944969/which-password-manager-is-the-most-secure


Some tags I'm worried about when parsing html doc for xxs

What you are trying to do is inherently pretty dangerous. I would strongly recommend using something like BBCode or Markdown, as these are specifically designed to allow fairly rich content without script injection risks (although bugs in them are sometimes found).

With that said, there's only two really obvious scripting risks I see in what you've posted here.

Click here! will create something that looks like a "normal" hyperlink but will execute code within your site's origin (like an XSS) when clicked. You may notice that this doesn't work on StackExchange (which uses Markdown).
You can embed scripting behavior in CSS. Very old versions of IE allowed the expression value in styles, which is just flat-out embedded script, but there's also a thing called "CSS Behavior` that allows attaching externally-specified scripts to elements. This is, in effect, the same as embedding script tags in the page.

Beyond that, though, allowing CSS in general is dangerous. Using CSS, a malicious user can completely overlay the page, changing or hiding certain content or even making the page look like something totally different from what it is.


What particular devices and processes are available to destroy hard drives, per DoD 5220.22-M?

There are facilities that provide this service. The facilities are often contracted in for facility-wide "shred-days." In house, the military has Defense Re-utilization and Marketing Office (DRMO.)  This office attempts to re-sell, or re-utilize equipment safe for use, or is often used in disposition.

Here's what Ive found:

Pulverizing:

Basically, this is a hammer mill that rotates. Centrifigul force pushes metal "planks" out that shmammer-the-heck out of the hard disk, until it is reduced in size enough to pass through the holes in the filter part of the chamber.

Watch hard drives being Pulverized @ YouTube

Disintegrating:

Basically, Disintegrating is shredding, but designed for use primarily on plastics such as CDs. This works in a very similar manner to a hammer mill, however it uses blades to cut/shred the items.

Watch paper, plastic, and a CD being disintegrated @ YouTube

Melting

Certain hard drives components are melted, such as the aluminum chassis, AFTER the disk has been destroyed through other means.

Watch hard drive melting @ YouTube

I hope this helps!


Consider getting a software product which fully encrypts your hard drives. Such a software will prompt the user to enter the password used to encrypt the hard drive during boot. Without the correct password, the hard drive (including both the OS and any data) can not be decrypted, the system won't boot and the user won't get any access to the data.

In that case a thief might still be able to sell the hardware by nuking the disks, but won't have access to any sensitive information stored on it.

The default solution for Windows is Microsoft BitLocker, which is already available out-of-the-box in some editions of Windows. There are also other products on the market like Sophos Safeguard or Truecrypt. For recommendations which product to use, consult Software Recommendations Stackexchange.


Would it be possible for me to become infected just by opening a Facebook message?

You are probably safe if these are true:

You didn't click the link*
Your browser is updated with the latest patches**
You aren't using any chrome or browser extensions***
Your computer is updated with the latest OS patches****

Generally, most exploits utilize well known vulnerabilities in common software like your browser, operating system, popular extensions, and common platforms. Vulnerabilities that are not well known are typically called zero-days. They cost (or sell for) a lot of money, and most people won't waste them on normal people. Nation states will buy them and use them to spy on other countries.

So, for most of us, keeping our software up to date is enough.

(*) it is possible that simply loading a message can kick off a CSRF and access other services that you use. If this was a common attack, your platform would be well known for allowing them. And so would the other site that let the CSRF through. Therefore, unlikely. Clicking a link can kick off more actions, like loading a malicious page. But even that is unlikely to affect you assume the other 3 things are in place.

(**) Your browser is your first line of defense. Keep it up to date.

(***) Browser extensions can break your browser's security model and allow attacks through. Only use them from trusted developers, or just don't use them unless you have to.

(****) Your last line of defense is your OS. Some browser exploits break out of the browser's sandbox, then need to take advantage of a vulnerability on the operating system. If you've closed the well known ones, your in the unlikely camp again, because nobody is wasting a zero-day on you.


How to block access from a single computer, other than blocking the IP?

A couple of ideas:

First, the obvious:

Change your public ip to other. So migrate the service and notify it to legitimate demo users.

Anyway this is not a definitive method, maybe other (or the same "evil" user) can scan and find you again.

Second one:

Use port knocking. This is a good solution to open services to internet you don't want to be abused. But the problem maybe could be "difficult" to open the port for some users. Not sure if you have a customer db which is supossed to use your free demo service. If you have it, maybe you can notify to all how to do it.

A little example. Let's suposse your service is using port port 12345 and you already have configured port knocking. Anybody scanning your public ip will have a "filtered" response on that port. You can set a combination of ports in order to open it only for the ip "knocking". Let's suppose the combination of ports to open it is 5555, 3432 and 10678.

You can send the instructions to your customers to open it using nmap doing:

for x in 5555 3432 10678; do nmap -Pn --host_timeout 201 --scan-delay 0.5 --max-retries 0 -p $x <yourPublicIp>; done

As I said maybe is too complicated for some customers. It depends of the kind of your customers. If they are IT staff they will have no problems.


Can you get a virus from sending a GET or POST request?

Yes, it depends how that GET/POST request is handled on the receiving party, i.e the client.

While explained in another thread "Yes, you can get a virus just by visiting a site in Chrome or any other browser".  This also counts for any client.  In this case: the program that's handling the response from your web request. No matter if that's a browser, CLI program, library, game, etc.  If a vulnerability exist in the client code which can be exploited, malicious code can be executed.  This malicious code is roughly what you refer to as "a virus".

There are mitigating factors such as isolation, exploit mitigation (DEP, ASLR, ...) but there's always a possibility that this is bypassed.

The worse thing that can happen is that an attacker can execute code on a victims machine, elevate privileges and execute system commands.  Examples?  Steal data, delete files, launch further attacks, ... If someone can execute code it's a complete compromise.


How to securely exchange a symmetric key over a unsecure netwrok

Let me first say, cryptography is hard and I highly recommend you do not attempt to invent a novel crypto system.

With that said, it seems you are interested in some form of ephemeral diffie-hellman key exchange.

Edit As pointed out in the comments, my initial answer was not thorough enough to be helpful

  I need to build a project for uni where I need to transfer data securely from a client to a server

If this is an academic project, and you assignment is to design a novel cryptosystem then you may want to go the the crypto stack exchange site. But if you are doing this to secure something out in the wild, my statement still stands, do not invent a novel cryptosystem.

  I need to transfer data securely from a client to a server. I can't use PKI structures and can't save pre-shared secrets (Imagine travelling to china and some bad guys check your pc). The only secret is the client's password, which got salted, hashed and saved into the database of the server.

You may want to assess this requirement and ask yourself or the person you are implementing this for: How do the client and the server know they are communicating with the correct entity? Anything you do without this assurance is not technically secure. This is why PKI exists.

Maybe your assignment is to implement something that builds on top of the Web of trust model. Something like Pretty Good Privacy (PGP) where the client initiates communication with the server using the public key of the server (which is technically not a secret). Even this is built on the assumption that the private key doesn't get into the hands of the wrong person.

  Is this really secure? How can I be sure that after inital "handshake", they are still the same?

You would have to ask someone who is an expert in cryptography, but I would say doing this step "Generate the hash on the client pc. Generate a key from this (using pdkf2) on the pc as well on the server. This key is now the symmetric key." without first preventing a MitM attack will break the security of the rest of the system.


Does Centralisation Decrease the Probability but Increase the Damage of Exploits?

The probability of exploits is a vague term.

What you've got in reality is the number of exploitable bugs in the code, the number of bad guys working to find them, and the number of good guys working to close them (it is useful to think of this stuff in terms of FTEs - full-time equivalents, even if many researchers (blackhats and whitehats) don't dedicate themselves 8/40 to the task at hand).

Centralization tends to increase the incentive to hack - the stakes are much higher. D3C4FF is right that this indeed puts all the eggs in one basket.

However, centralized organizations can afford spending money on hiring the good guys (ex-bad guys in some circumstances). Large firms have the brains and dedication and foresight to make some of the staff available for security research instead of toiling like monkeys for immediate monetary gratification of the shareholders. IBM and Microsoft are prime examples, IMHO.

Centralized organizations can be practically considered monopolies; it is often surmised that monopoly status makes companies lazy and overly arrogant (Oracle, I'm looking at you re: Java patching!).

The resulting interplay of psychological, organizational and sheer quantitative factors gives a very rich picture.

To sum it up, the risks are greater, the potential for losses is getting enormous, but there are some forces that mitigate the risks. It would be very rash to say that probability of exploits goes down.


What is the best way to protect an encryption key?

You must store keys in such a way to minimize risks of the key being exposed to unauthorized third parties, while still allowing efficient operation by systems which must use the key. If such a system (your "server") comes under hostile control, then you have lost anyway. So the question about where the key should be stored really makes sense only with regards to partial breaches, in which an attacker gains some access to a part of the server, not to the whole thing.

That's about the most that can be said generally. Context matters.

If your context is about some sort of Web server, powered by some programmatic framework (say, PHP) with a SQL database for data storage, then we may argue that a very common kind of partial breach is SQL injection, which primarily allows the attacker to get read-only (or read-write) access to (parts of) the database, without directly impacting the security of the server itself. In that sense, the database may be said to be "more exposed" than the rest of the server; correspondingly, the keys should not be stored in the database itself. However, remember that this is only a very generic assertion which does necessarily apply to your specific case. Context matters.

Still generically, we may state that if your operating system offers some facilities dedicated to the storage of secret values, then using them is probably a good idea. In a Windows system, this points to DPAPI. Whether it will actually help is unclear (it, again, depends on the context -- the context matters) but it should not make harm.


This depends on the type of encryption you are using and possibly how it is configured.  You are correct that certain types of stream cipher require all previous data to continue to decrypt, due to the encryption operation modifying the key stream, however not all encryption works in this mode.

In particular, for file system level encryption, it is obviously not viable to have to sequentially decrypt the entire drive as one giant stream in order to access any particular file.  The exact mechanism of encryption can vary, but can be anything from stream ciphers of individual files (which might still cause performance issues with larger files that need random access) or simply applying sector or cluster level encryption that limits the amount that needs to be decrypted to a minimal data retrieval from the drive.

There is always a trade off in the security and uniqueness of the keystream vs the speed of access, just like there are trade offs in different cipher modes, but full disk encryption is not inherently tied to a single bad sector causing a complete loss of data.  The exact amount of data loss would depend on the type of encryption being used.

The same applies to your scenario with smaller containers being used on the drive as files.  Depending on the mode of those containers, it could either require sequential decryption of the whole thing (which would mean a single sector used in the file dying could wipe it out) or it could be done at a file level where only the involved files would be lost.  The container could also potentially work in a level of redundancy to avoid this, though I'm not sure if any encrypted containers currently implement a feature like this.


Once you say the magic words "targeted attack", I'm not sure that theory has much to say on the topic.

The whole idea of password entropy only makes sense against a generic dictionary / rainbow table attack. Basically, the online entropy estimators are trying to estimate how far an attacker will have to delve into their rainbow table before they find your password. These are based on publicly available rainbow tables.

As you say, only a randomly machine-generated password [1] [2] stands up to Kerckhoffs's principle. As soon as an attacker decides to launch a targeted attack and study your password habits, the entropy value provided by those online estimators no longer makes any sense. By sniffing your TLS packets, they can tell the length of your password, by looking up your email address in databases of leaked passwords [1] [2] they can tell what patterns you like to use for your passwords, etc. They can use information like that to build a targeted rainbow table or brute-force dictionary against which your password will have a significantly lower entropy.

Bottom Line: online entropy estimators are based on what researchers think attackers are using for rainbow tables in a generic attack, and apparently ham,ham,ham,bacon,bacon,ham stands up fairly well against that. Any estimate of how well it would stand up against a actual targeted attack is pure speculation.


How can I see traceroute details in NMAP?

Try with this command

nmap -sn --traceroute <remote_ip>

And lookup these:

https://serverfault.com/questions/432017/whats-going-on-with-traceroute

https://svn.nmap.org/nmap/zenmap/share/zenmap/config/scan_profile.usp

http://seclists.org/basics/2011/Mar/19


What is the "Moose" worm and how can I protect myself from it?

ESET released a report about the vulnerability here. Their key findings are:

  Linux/Moose targets consumer routers and modems including the hardware provided by Internet Service Providers (ISPs) to consumers
  The threat is built for deep network penetration spreading past firewalls
  It can eavesdrop on communications to and from devices connected behind the infected router, including desktops, laptops and mobile
  phones
  Moose runs a comprehensive proxy service (SOCKS and HTTP) that can be accessed only by a specific list of IP addresses
  The operators use the infected devices to perform social network fraud on Twitter, Facebook, Instagram, Youtube and more
  Moose can be configured to reroute router DNS traffic, which enables man-in-the-middle attacks from across the Internet
  It affects Linux-based embedded devices running on the MIPS and ARM architectures

If we look at how it spreads one statement is very important here:

  Last but not least, this threat spreads only by compromising systems
  with weak or default credentials. No vulnerabilities are exploited by
  the malware. Although downplayed by system administrators, this attack
  vector has been effective at compromising a lot of Internet-connected
  systems. As FireEye recently stated: “Brute forcing credentials
  remains one of the top 10 most common ways an organization is first
  breached.

They have listed a some of the devices which may be affected:

Network equipment vendors

3Com, Alcatel-Lucent, Allied Telesis, Avaya, Belkin, Brocade, Buffalo, Celerity, Cisco,
D-link, Enterasys, Hewlett-Packard, Huawei, Linksys, Mikrotik, Netgear, Meridian, Nortel,
SpeedStream, Thomson, TP-Link, Zhone, ZyXEL

Appliances vendors

APC, Brother, Konica/Minolta, Kyocera, Microplex, Ricoh, Toshiba, Xerox

Internet of Things vendors

Hik Vision, Leviton

Indicators of compromise

  If the credentials can be used via Telnet to login, if Telnet is
  enabled by default and if a shell access can be obtained by typing sh
  in the device’s prompt, then these are very good indicators that a
  device could be infected by Linux/Moose.

Prevention

  Change default passwords on network equipment even if it is not
  reachable from the Internet. Disable Telnet login and use SSH where
  possible. Make sure that your router is not accessible from the
  Internet on ports 22 (SSH), 23 (Telnet), 80 (HTTP) and 443 (HTTPS). If
  you are unsure about how to perform this test, when you are at home,
  use the "common ports" scan from the ShieldsUP service from GRC.com.
  Make sure that the above mentioned ports receive a Stealth or Closed
  status. Running the latest firmware available from your embedded
  device vendor is also recommended.


This appears to be a bot looking for common vulnerabilities in websites. Such bots are very commonly run by black-hat hackers to identify potential hacking targets. All websites get scanned by such bots regularly. It is unlikely to be an attack specifically targeted at you.

The only useful defense is to make sure that you don't have any vulnerable web applications on your site. If you use any standard software on your server (on the whole stack from operating system to individual scripts), make sure they are always up to date.


Is all Snort community rules available in Snort registered rules?

Is all snort community rules available in snort registered rules ?

Yes. snort Registered ruleset contains the Community ruleset. Ref

  or shall I include registered rules only in my snort?

It is recommended that you use both the Registered Ruleset and the community ruleset, if you are not going to become a subscriber. Ref


CVE-2017-15580: Getting code execution with upload

I don't think that you read the CVE or the PoC properly.
The PoC says that the reverse shell is to get a shell "of the end user". Not the server.
So, you are not doing anything wrong. You are just expecting something that is not meant to happen.


Is it possible to guarantee a transaction between two peers against interruption exploits?

The situation you describe assumes that both Alice and Bob are not in full control of the device and software because otherwise Alice could use a modified software which prevents the deletion of the local Pokemon.
If this assumption is true, i.e. Alice cannot tamper with the device and software, one could do the transfer in multiple steps:

Alice creates a random key and encrypts the Pokemon
Alice sends the encrypted Pokemon to Bob but not yet the key. Alice waits for confirmation that Bob received the encrypted Pokemon.
Alice deletes the local Pokemon.
Alice sends the encryption key to Bob until it gets a confirmation. Bob confirms after successful decryption. Only after the confirmation both destroy the no longer needed key.

If the initial assumption is not correct, i.e. if Alice can actually modify the software which is in control of the exchange, then you need some external service where all parties can verify who owns a specific Pokemon now. While this will not make cheating impossible it can be used to detect if a Pokemon is used by somebody who does not own it.  As indicated in a comment, Bitcoin is one way to run such a service.


Passing user identity to an internal REST service

I have almost exactly the same issue with two services of mine.

I'm taking a slightly different route to solve it due to the following train of thought: What happens if due to some misconfiguration of the firewall or a router, service B suddenly becomes available on the internet, or on the internal network of my company? We've had firewall rules change without being told about the changes in the past; so I've grown careful.

Here's what I'm currently doing: Service A and B share a secret password which only they know. I use it to build an hmac over a small json structure (my "access token") on service A which basically contains the user name of the authenticated user, a nonce and an expiry date. I pass the access token and the hmac to service B (as a long base64-encoded string in the standard Authorization header). Service B then validates the access token using the hmac and if it checks out, it can be reasonably sure that the access token it received was from service A. All that remains is to make sure that the access token has not expired.

You could do the same with a JWT, and with public key cryptography to digitally sign the access token, instead of what I'm doing with an hmac.

This isn't so much different from what you're doing - building my access token (just once, when the user logs in on service A) isn't much work, and neither is verifying the token on service B, but it does add some additional security, compared to your solution.

Just like you, I'd be interested in answers which describe a generally accepted way of solving this issue - I've always thought my solution was a bit too home-grown, and might suffer from problems I can't immediately see.


Is it possible to dump an exe from ram and create a distributable exe from it?

It's possible to design operating systems, or individual programs, so this is possible.  With debugger-level access to a running application, you could probably reconstruct a close approximation to the the exe which launched it.  However, that wouldn't necessarily put you in any better position to distribute the app than if you just copied the original bits.


VPN - Why is my NAT'ed Laptop being SSH-brute-forced by External IPs when in VPN?

Although I don't know the exact configuration of your device and network I can suggest a scenario that matches what you're seeing.

On your local lan you have a network adapter (let's say eth0) which has an internal non-routable IP address which is behind a NAT interface and firewall, so can't be directly contacted.

When you connect to your VPN it'll bring up another network interface (e.g. tap0) which creates an encrypted tunnel out of your network to your VPN provider.  At that point it's entirely possible that the IP address you get from your VPN provider is essentially a publicly routable one, which isn't protected by your home firewall as the tunnel bypasses this.

So if your network services (e.g. SSHD) are configured to bind to all network interfaces on your system (a pretty common configuration) when you bring up the VPN interface they'll bind to that too, then if it gets a publicly routable address they'll be "exposed" to the Internet.

You can check this by doing something like ifconfig to get a list of interfaces and IP addresss and then sudo netstat -tunap which should show what interfaces your network services are bound to.

If you see [your_vpn_address:22] or [0.0.0.0:22] then that would explain what you're seeing.


Why would someone register a Facebook account with a stolen email address?

Two possible scenarios that pop into my mind:

Since we can assume the attacker probably had access to his email, he probably had access to his address-book as well and he could have requested friendship (search for friends by email address) from all the people that had a facebook account registered to one of the email addresses from that address-book (some of those requests would succeed). Despite having a different name (lots of people don't use their real names on facebook), lots of people would accept the invite either blindly or since they would see they had friends in common (the ones that accepted blindly). After that, he would have access to additional data about all that other people, etc..
He could just let the facebook account lay there and wait for someone else to find him by searching friends by email after which, he would again have access to additional data.


Yes you are right, someone could intercept the communications and log in as the user, also you are doing a lot of extra unnecessary work on the client. Here is the steps I would do

User submits their data
Client establishes a secure link to the server (SSL or similar)
Client sends their username and password over the secure link to the server.
The server looks up the username in the database and retrieves the salt, the iteration count, and the hashed password
The server runs the sent password, the looked up salt, and the looked up iteration count through a proper password derivation function like bcrypt or pbkdf2
The server compares the output of the previous function to the hashed password it looked up

(optional) If the password was correct, the server checks to see if you have raised the minimum iteration count for the server, if the user's account is below the minimum the server will run the password through again at the new iteration count level with a new salt and record the new hash, the new count, and the new salt in the database.

Client receives 'true' or 'false' over the secure link depending if it's the correct password


Requesting a CVE for unpublished vulnerability in open-source project?

My suggestion is to make sure the issue is fixed in the project, post it to Full Disclosure and then use that post to request the CVE.


How should we apply the salt to the password?

Say I'm using Argon2(di) to store passwords. Should I use the second method or first method to hash passwords?

No. Argon2 takes the salt as a separate argument from the password, and takes responsibility internally about how to incorporate them both into the computation.  As any specialized password hashing function should.

Ideally, though, you should use a higher-level API that takes care of salt generation and management internally, by encapsulating the use of the password hash with:

An "enrollment" function that takes a password, generates a salt, and outputs a verification string that encapsulates choice of hashing algorithm, algorithm parameters, salt and hash.  See for example the password_hash() in PHP.
A "verification" function that takes a password and verification string, parses the latter to recover all those parameters, and verifies that the password matches.  See, e.g., password_verify() in PHP.

Basically, if you're manually concatenating salts and passwords like your quote from Wikipedia suggests, you're doing it wrong.


Python generated RSA keys looks the same

The two large primes that make up the RSA private key are different each time you run the script.
I added a line to the end of your script, to output the RSA private key in PEM format produced by the script:
from Crypto.PublicKey import RSA
from Crypto import Random

random_generator = Random.new().read
prv = RSA.generate(4096, random_generator)

print(prv.exportKey().decode())

Then, I saved the script as genrsa.py.  If you run genrsa.py, you'll see that it produces an RSA private key, in PEM format.
Try running the script, and redirect the output to a file called privatekey.pem:
 python3 genrsa.py > privatekey.pem

Now, use openssl to examine the contents of privatekey.pem:
openssl rsa -noout -text -inform PEM -in privatekey.pem

Look at the two primes.  Then, repeat the steps above, and compare the two primes created in the second run to those created in the first run.  The two pairs are very different.
With regard to the question about why the beginning and ending bytes of the PEM file produced are always the same - this has to do with the RSA format itself, and the ASN.1 and DER encoding standards that are used to create PEM files.  See https://stackoverflow.com/questions/18039401/how-can-i-transform-between-the-two-styles-of-public-key-format-one-begin-rsa for more information.
For more information on the anatomy of an RSA private key PEM file, and how you can examine the underlying components of the private key contained in the file, see: https://crypto.stackexchange.com/questions/45151/anatomy-of-an-rsa-private-key.


What about SSL makes it resistant to man-in-the-middle attacks?

My client will ask the certificate issuer if the server I contacted is really the server it says it is, the certificate issuer will propose a challenge to the server, and respond to me if it went well.

No, you don't have to separately contact the issuer to verify a certficiate. Otherwise you would just be shifting the trust problem. Instead there has to be a local trust anchor.

That's why your browser (and eventually your OS) already comes with pre-installed certificates for certificate authorities that were deemed to be trustworthy. From the Mozilla CA Certificate Policy:

  When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products, Mozilla may include with such software a default set of X.509v3 certificates for various Certification Authorities (CAs). The certificates included by default have their "trust bits" set for various purposes, so that the software in question can use the CA certificates to verify certificates for SSL servers and S/MIME email users without having to ask users for further permission or information.

When your browser establishes an SSL connection to facebook.com, the server presents the certificate along with a signature to prove that this certificate was issued by DigiCert for the domain facebook.com. The browser checks this by verifying that the certificate is transitively signed by DigiCert's root certificate that came with the browser. If the corresponding root certificate can't be found or isn't trusted, then there is no valid certificate chain and the verification fails.

As an additional security mechanism Facebook uses the HTTP Public Key Pinning (HPKP) feature which stops a man-in-the-middle attacker even if they managed to compromise a CA and generate seemingly valid certificates:

  The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser.

(Source)

While any website can announce their own pins via a Public-Key-Pins header that will become active after your browser's first visit (TOFU model), Facebook and some other high-profile sites have their pins built-in in Firefox and Chrome, meaning that these browsers trust Facebook's certificates directly and don't need to check with the DigiCert root at all.

Also note that there are independent mechanisms where clients do actually contact a CA directly. For example, your browser can use OCSP to check a particular certificate's revocation status.

Also see:

How are Chrome and Firefox validating SSL certificates?
What is an SSL certificate intended to prove, and how does it do it?
How are SSL certificates verified?


Why would a scammer not reply with the same email?

They might be load-balancing internally.

Let's say you are dealing with a team of 10 scammers who spam 10,000,000 people and assume that about 200 marks reply. How do they make sure those 200 marks are evenly distributed on their 10 people? By having them all reply to the same address and then distribute them internally. Whoever gets assigned to the mark then replies from their own email so all further correspondence goes through their personal mailbox.

Or they might even go a step further and give each mark an own mailbox to converse with so the scammers don't mix up their marks. A mark might suddenly reply from a different account or accidentally start a new email thread just mentioning "the deal we agreed on". When a scammer operates on multiple marks at the same time (and most scammers do) then they really don't want to be confused by that and risk breaking the illusion that the mark is in some unique negotiation with a private person.


What's the difference between a hashed and an encrypted password?

Encryption vs. Hashing

Nobody really "encrypts" a password, although you could... but you'd be encrypting it with another password, and you would need that password to decrypt the first password. When it comes to passwords, we normally hash them.

Hashing is simply one-way. You cannot get the string back, you can only check to see if a string validates against a hash. If your string validates against the hash, this does not guarantee that it's the same "password," but you can log in with it because you've found a collision. The "message"/password is usually limited to a small number of characters, relatively speaking.
Encrypting is two-way. For example, you have an algorithm, a key, and a message. Using the key, you can unlock the message. Usually, the message could be of arbitrary size.

Makeshift Flowchart Examples

I made a couple flowcharts that are overly simplified. Hope it helps.

See the above? It doesn't make any sense that you would get the "message" back. Why? You're already entering the password, which is the "message" itself.

Now look at this:

With encryption, you're getting the decrypted message back if the decryption key is correct. You use the key to unlock the encrypted contents.

With hashing, you already have the "message" if it validates, or a collision. What you enter is the message.


Potentially, sure.

If permissions are viewable, that gives an attacker a list of valid usernames and tells the attacker which accounts are the best candidates to attack.  An attacker is much more likely to want to break in to the jdoe account in the HR system if they know, for example, that jdoe has the ability to see everyone's salary.

Making permissions viewable also makes it much more likely that other security shortcomings are going to be exploited.  If someone forgot to remove the jdoe account when he was fired, for example, or if someone inadvertently assigned privileges to jdoe rather than janedoe, viewable privileges lets the attacker see immediately where the weak points are and figure out how to craft an attack to stop it.

Of course, the attacker still has to craft an appropriate attack-- whether technical or social-- to exploit the information they get from being able to view other users' privileges.  It just makes it quicker, easier, and safer to mount the attack if you know where the pressure points are.


Is CAST5-CBC as supported by OpenSSL an authenticated encryption method?

The reason AES-CBC isn't an authenticated mode has everything to do with the CBC and nothing to do with the AES. CAST5-CBC isn't inherently authenticated either; changing one bit in the IV changes the corresponding bit in the first block, and there's no way to detect it, because that's a result of the CBC construction and not of the cipher.


Is it safe to use .netrc files to store credentials for tools like curl or ftp?

Storing credentials in clear-text on your computer is a risky business as any application that runs on your computer has access to these credentials. The credentials are also exposed in backups, zips, etc...

.netrc files are a prime target for attackers looking to branch out to other computers.