I can see the T shirt now. Photo: Tied off shirt, daisy dukes, heels, hair, makeup. Caption: “I should have never learned to code.”
From: Josh Luthman Sent: Monday, March 09, 2015 9:38 AM To: [email protected] Subject: Re: [AFMUG] Powercode oddity - Commerzbank Ip space AFMUG 2016 Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mar 9, 2015 11:36 AM, "Chuck McCown" <[email protected]> wrote: I think we need photos... From: Simon Westlake Sent: Monday, March 09, 2015 9:30 AM To: [email protected] Subject: Re: [AFMUG] Powercode oddity - Commerzbank Ip space I had to reread that second paragraph at least 3 times. You've awakened feelings in me I didn't know I had. On 03/09/2015 10:07 AM, That One Guy wrote: I suspected it was discovered, and v10 specifically broke the miner and the code that called these IPs from a list somehow put them in there. If I were a developer I would do things like that, which is why God intervened everytime I tried to learn to code. I would be in prison, I would be very pretty, the koolaid lipstick would make my lips cherry red, and my shirt would be tied in a knot while my milkshake brought all the boys to the yard. Good thing for me I never learned to code On Mon, Mar 9, 2015 at 10:01 AM, Simon Westlake <[email protected]> wrote: I think your tinfoil hat is a little tight.. ;) If we were going to use your billing server as a bitcoin miner, why would we only change the IPs when a customer updated their equipment in the portal? And why would we even make it visible? If I really wanted to hide a bitcoin miner on your billing server, I wouldn't do it by sending your customers to the redirect page.. On 03/09/2015 09:57 AM, That One Guy wrote: me and my tinfoil hat find it suspiscious that v10 resolved the constant overloaded billing servers and this pops up, like there is a list somewhere and since the first one I saw was affiliated with bitcoins, Paranoid me assumed a developer sometime in the historical chain realized there were alot of unused cycles out there under their control. On Mon, Mar 9, 2015 at 9:51 AM, Josh Luthman <[email protected]> wrote: Look up variable declaration types. I'm willing to bet someone did the math wrong. I've seen it a couple times before but I can't recall where. While the IPs look random, they're not. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mar 9, 2015 10:47 AM, "That One Guy" <[email protected]> wrote: Where are these IPs coming from. and this is a direct serious question, at any point in time, whether as a product of bertram or the previous developers, were billing servers used as a distributed bitcoin mining system? On Mon, Mar 9, 2015 at 9:37 AM, Simon Westlake <[email protected]> wrote: It's not database corruption, but it is a known bug (IP changing when MAC is edited in customer portal) and it's fixed in 10.03.32. The patch will be out this week. On 03/08/2015 10:34 PM, Jeremy wrote: Yes, it seemed like a database corruption issue to me as well. I had one customer get the redirect and I went in and looked and he was on a completely wrong IP (in a subnet that I happened to be working on earlier that day and the evening before). He hadn't even logged into the customer portal. The logs didn't show any IP change, but clearly his IP was changed in the database, as he was working fine on the same IP for months and months. That issue and the incorrect assignments when a customer enters a new MAC seemed related to me. On Sun, Mar 8, 2015 at 9:26 PM, CBB - Jay Fuller <[email protected]> wrote: ----- Original Message ----- From: Jay Fuller - Cyber Broadband Inc To: Powercode Cc: Cyber Broadband Inc. Sent: Monday, February 02, 2015 7:34 PM Subject: Re: Ticket Updated [Ticket Number:5841] - weird ip changes during customer portal equipment edits Gentlemen: It has happened again. xxxxxxxxxxxxx, customer 1478, requested a public routable IP address which is in a different address class from what he was assigned at installation. Upon changing the address, he was assigned 104.152.40.91, which is an available address in the "Cullman Public" address range. However, when looking at the ARP response (because the customer is bridged to our main router), I saw another network device already had that IP address. So, I searched for that MAC address, which was 78:24:AF:7B:49:38 , using equipment search, which came back to customer 514, xxxxxxxxxxxxxxxxxxxxx, who had logged into the customer portal on January 29 to install a new router. Upon changing his MAC address, powercode assigned him 104.153.191.25, which is not even in any of our network address ranges. It belongs to: Source: whois.arin.net IP Address: 104.153.191.25 Name: IMDC-KC-LOOPBACKS Handle: NET-104-153-191-0-1 Registration Date: 2/2/15 Range: 104.153.191.0-104.153.191.31 Org: Iron Mountain Data Center Org Handle: IMIML Address: One Federal Street City: Boston State/Province: MA Postal Code: 02111 Country: UNITED STATES This is very similar to our new public IP range which is 104.152.40.0/22 Incidently, it appears this customer was assigned 104.152.40.91 before he attempted to edit his equipment and was changed to 104.153.191.25. Also of note, it appears this only affected the GUI/web interface of powercode, and the router/bmu continued to assign him 104.152.40.91. I will now have to reassign xxxxxxxxx a new IP address since the web/gui gave his IP address to someone else. I hope this information helps you to figure out what is happening. I am still concerned we have some kind of database issue. Weird things like this seem to be happening a lot. Thanks. ----- Original Message ----- From: Powercode To: Cyber Broadband Sent: Thursday, January 22, 2015 2:15 PM Subject: Ticket Updated [Ticket Number:5841] ---------------- Please reply above this line ---------------- Good afternoon Jay, We were able to test from this customer's account, and the same issue that was originally reported to us persisted. We logged into the customer portal, changed the MAC address by one digit, and immediately the customer was issued an IP address of 192.170.241.173. After changing the MAC address back to his current valid one, we then had to manually clear out his IP address in Powercode in order for the BMU to hand out a reservation for 192.168.3.36 via DHCP. At this point, we are going to contact our network engineers for assistance in troubleshooting why this customer would receive a 192.170.xx.xx reservation, as this IP does not fit within any ranges defined in Powercode. We will update you as soon as we've had a chance to go over this with them. -------------------------------------------------- Have you visited our knowledge base? The Powercode knowledge base contains data on all aspects of Powercode, including the BMU. You may also find useful information on our community forum. We endeavor to respond to all tickets within two business days. Our business hours are Monday - Friday, 9AM to 5PM Central time. Please contact us via telephone at (920) 351-1010 or via Skype at powercode_support with any urgent needs. -- John Mahnke Powercode - The smart choice in ISP billing and OSS powercode.com P: 920-351-1010 E: [email protected] ----- Original Message ----- From: Jeremy To: [email protected] Sent: Sunday, March 08, 2015 9:25 PM Subject: Re: [AFMUG] Powercode oddity - Commerzbank Ip space I also have a ticket in about this issue. On Sun, Mar 8, 2015 at 2:10 PM, That One Guy <[email protected]> wrote: This is known to them? (powercode) On Sun, Mar 8, 2015 at 3:00 PM, CBB - Jay Fuller <[email protected]> wrote: yes, they're aware of it. i pointed this out to them weeks ago. :( ----- Original Message ----- From: That One Guy To: [email protected] Sent: Sunday, March 08, 2015 2:06 PM Subject: [AFMUG] Powercode oddity - Commerzbank Ip space I am able to replicate a small issue we are having, trying to make the decision of whether it looks like a security issue or just a bug. Through powercode, there are two ways to update equipment, through our interface, where we select all the details and through the customer portal where all the customers can do is update their MAC address. no problems with our end. However, when a customer updates their MAC address, it is assigning IP space that apparently belongs to this Commerzbank IP space 208.74.54.100 and 208.74.54.99. This IP space is absolutely not in our system, and wouldnt route naturally on our network Net Range 208.74.52.0 - 208.74.55.255 CIDR 208.74.52.0/22 Name DKIB-USA Handle NET-208-74-52-0-1 Parent NET208 (NET-208-0-0-0-0) Net Type Direct Assignment Origin AS Organization Commerzbank AG (COMMER-109) My initial thoughts are this is some bug in powercode. Paranoid me is that our system is somehow compromised and rerouting illegitimate traffic somehow. Customer is down, so not through them. but something like TOR rerouting or some other magician script for the axis of evil. Anybody have any ideas on this? I am debating taking our billing server offline, but would hate to take such an extreme measure for what could amount to nothing more than a fat finger from a programmer. -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team. -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team. -- Simon Westlake Powercode - The smart choice in ISP billing and OSS powercode.com P: 920-351-1010 E: [email protected] -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team. -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team. -- Simon Westlake Powercode - The smart choice in ISP billing and OSS powercode.com P: 920-351-1010 E: [email protected] -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team. -- Simon Westlake Powercode - The smart choice in ISP billing and OSS powercode.com P: 920-351-1010 E: [email protected]
